Skip to main content

Extended YANG Data Model for DOTS
draft-cui-dots-extended-yang-02

Document Type Active Internet-Draft (individual)
Authors Yong Cui , Linzhe Li
Last updated 2024-09-05
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-cui-dots-extended-yang-02
IETF                                                              Y. Cui
Internet-Draft                                       Tsinghua University
Intended status: Informational                                     L. Li
Expires: 10 March 2025                           Zhongguancun Laboratory
                                                        6 September 2024

                   Extended YANG Data Model for DOTS
                    draft-cui-dots-extended-yang-02

Abstract

   With the development of DDoS defense technologies, the interfaces and
   parameters defined by DOTS are no longer sufficient to support the
   collaborative signaling required between DDoS mitigation systems.
   This document defines three YANG model to extend the data models of
   existing interfaces on the DOTS signaling and data channels, with the
   aim of supporting the transmission of necessary collaborative
   information between DDoS mitigation systems via DOTS and enabling
   efficient collaborative mitigation based on this information.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 10 March 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components

Cui & Li                  Expires 10 March 2025                 [Page 1]
Internet-Draft      Extended YANG Data Model for DOTS     September 2024

   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Context and motivation  . . . . . . . . . . . . . . . . .   2
     1.2.  2.  Terminology . . . . . . . . . . . . . . . . . . . . .   3
   2.  Problem statement . . . . . . . . . . . . . . . . . . . . . .   3
   3.  YANG Models . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Extended YANG models for signal channel . . . . . . . . .   5
     3.2.  Extended YANG models for data channel . . . . . . . . . .   8
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .  13
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

1.1.  Context and motivation

   DDoS attacks have been a persistent network security issue plaguing
   global network operators and software providers.  With the growth of
   global networks, DDoS attacks have increased in scale, frequency, and
   the emergence of new types, leading to a heightened focus on
   coordinated attack response and standardization.  [RFC8612] defines
   the DDoS Open Threat Signaling (DOTS) protocol for coordinating
   responses to DDoS attacks.  DOTS can be utilized by any device or
   software system involved in DDoS mitigation, allowing both parties
   involved in the coordination to exchange necessary information such
   as collaborative mitigation requests and monitoring data.

   As DDoS mitigation technologies evolve, DDoS protection devices and
   software systems have expanded their functionalities, yet DOTS has
   not been adapted to incorporate these updates.  In order for
   collaborative mitigation parties to formulate more effective
   mitigation strategies and respond more quickly to collaborative
   mitigation requests, it is necessary to extend the functionality
   interface and parameter model of DOTS.

   This document defines three data models for extending the existing
   DOTS interfaces, enabling DOTS to support the transmission of crucial
   information required for collaborative mitigation.

Cui & Li                  Expires 10 March 2025                 [Page 2]
Internet-Draft      Extended YANG Data Model for DOTS     September 2024

1.2.  2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   These capitalized words are used to signify the requirements for the
   DOTS protocols design.

   This document adopts the following terms:

   DDoS: A distributed denial-of-service attack in which traffic
   originating from multiple sources is directed at a target on a
   network.  DDoS attacks are intended to cause a negative impact on the
   availability and/or functionality of an attack target.  Denial-of-
   service considerations are discussed in detail in [RFC4732].

   Mitigation: A set of countermeasures enforced against traffic
   destined for the target or targets of a detected or reported DDoS
   attack, where countermeasure enforcement is managed by an entity in
   the network path between attack sources and the attack target.
   Mitigation methodology is out of scope for this document.

   Mitigator: An entity, typically a network element, capable of
   performing mitigation of a detected or reported DDoS attack.  The
   means by which this entity performs these mitigations and how they
   are requested of it are out of scope for this document.  The
   mitigator and DOTS server receiving a mitigation request are assumed
   to belong to the same administrative entity.

   DOTS client: A DOTS-aware software module responsible for requesting
   attack response coordination with other DOTS-aware elements.

   DOTS server: A DOTS-aware software module handling and responding to
   messages from DOTS clients.
   The DOTS server enables mitigation on behalf of the DOTS client, if
   requested, by communicating the DOTS client's request to the
   mitigator and returning selected mitigator feedback to the requesting
   DOTS client.

2.  Problem statement

   To illustrate the collaboration for DDoS mitigation systems, the
   following workflow should be established for efficient collaboration:

Cui & Li                  Expires 10 March 2025                 [Page 3]
Internet-Draft      Extended YANG Data Model for DOTS     September 2024

   *  The client sends predetermined configuration information to the
      server, including but not limited to mitigation strategies and
      required mitigation resource capacity.

   *  Upon receiving the predetermined configuration request, the server
      determines based on its own capabilities whether to accept the
      installation.

   *  When collaboration is needed for mitigation, the client initiates
      a collaborative mitigation request to the server.  The mitigation
      request should include important information such as attack
      characteristics, mitigation scope, and mitigation strategies.

   *  The server receives the mitigation request and forwards it to the
      mitigation party, utilizing the information within to confirm the
      authenticity of the attack and decide on responding to the
      collaborative mitigation request.

   *  The mitigation party formulates and executes the mitigation
      strategy.  The server sends a confirmation response to the client.

   *  Continual exchange of monitoring information can occur between the
      server and client.  The mitigation party can dynamically adjust
      mitigation strategies based on the monitoring information.

   *  After collaborative mitigation ceases, the server should send a
      mitigation report to the client.

   To improve collaborative mitigation efficiency, it is essential to
   pre-configure mitigation strategies and mitigation resource
   capacities.  These can assist clients in initiating requests to
   appropriate mitigation parties and enable mitigation parties to
   establish mitigation strategies.  Currently, DOTS only supports the
   installation of ACL rules, lacking other widely used mitigation
   methods such as BGP Flowspec.  Additionally, DOTS does not support
   the installation of mitigation resource capacity information, making
   it difficult for targets to identify the optimal collaborative
   mitigation party when facing attacks of different scales.

Cui & Li                  Expires 10 March 2025                 [Page 4]
Internet-Draft      Extended YANG Data Model for DOTS     September 2024

   Within the mitigation request data model defined in DOTS, only
   descriptions of the mitigation scope are included, such as IP
   addresses and protocols.  In the absence of commercial cooperation,
   these basic information pieces are insufficient to help mitigation
   parties identify attacks associated with mitigation requests and
   develop appropriate mitigation strategies based on the attack
   situation.  Therefore, it is necessary to define an extended attack
   description model in the signaling channel, allowing mitigation
   parties to quickly and accurately identify associated attacks.  These
   attack characteristics can also guide mitigation parties in
   formulating reasonable mitigation strategies.

   When requesting mitigation, providing baseline information,
   mitigation suggestions, or specifying mitigation strategies is also
   essential.  The key role of mitigation is to differentiate between
   attack packets and non-attack packets.  The targeted entities usually
   have extensive learning experience on their normal business packets
   or statistical data, enabling them to accurately identify the
   differences between attacks and legitimate requests, thereby
   filtering attack traffic more accurately.  Sharing baseline
   information, mitigation suggestions, and mitigation strategies can
   fully utilize the knowledge of the requesting party to help the
   mitigation party formulate effective mitigation strategies.

3.  YANG Models

3.1.  Extended YANG models for signal channel

   module: ietf-dots-extended-signal-channel
    +--rw dots-signal
       +--rw attack-details
       |  +--rw packet-feature
       |  |  +--rw port-number              inet:port-number
       |  |  +--rw average-packet-length    unit32
       |  |  +--rw duplicate-content        string
       |  +--rw statistical-feature
       |  |  +--ro bps-avg               unit32
       |  |  +--ro bps-peak              unit32
       |  |  +--ro pps-avg               unit32
       |  |  +--ro pps-peak              unit32
       |  |  +--ro bkts-avg              unit32
       |  |  +--ro bkts-peak             unit32
       +--rw mitigation-strategy  list
       |  +--rw name              string
       +--rw mitigation-advice    list
       |  +--rw description       string

   Figure 1: DOTS Extended Signal Channel Tree Structure

Cui & Li                  Expires 10 March 2025                 [Page 5]
Internet-Draft      Extended YANG Data Model for DOTS     September 2024

   file "ietf-dots-extended-signal-channel@2024-02-20.yang" module ietf-
   dots-extended-signal-channel { yang-version 1.0; namespace
   "urn:ietf:params:xml:ns:yang:ietf-dots-extended-signal-channel";

   grouping packet-feature {
     description
        "Packet-level characteristics of DDoS attack events.";
      leaf port-number {
        type inet:port-number;
        description
          "Target port number of the attack packet.";
      }
      leaf average-packet-length {
        type inet32;
        units "byte";
        description
          "Average length of attack packets.";
      }
      leaf duplicate-content {
        type string;
        description
          "Duplicate content in the attack packet.";
      }
   }

   grouping statistical-feature {
     description
        "Statistical characteristics of DDoS attack events.";
      leaf bps-avg {
        type inet32;
        description
          "Average bps.";
      }
      leaf bps-peak {
        type inet32;
        description
          "Peak bps.";
      }
      leaf pps-avg {
        type inet32;
        description
          "Average pps.";
      }
      leaf pps-avg {
        type inet32;
        description
          "Peak pps.";
      }

Cui & Li                  Expires 10 March 2025                 [Page 6]
Internet-Draft      Extended YANG Data Model for DOTS     September 2024

      leaf kbps-avg {
        type inet32;
        description
          "Average kbps.";
      }
      leaf kbps-avg {
        type inet32;
        description
          "Peak kbps.";
      }
   }

   typedef mitigation-strategy{
     leaf name{
       type: string;
       description
          "Name of the mitigation policy installed on the server.";
     }
   }

   typedef mitigation-advice{
     leaf description{
       type: string;
       description
          "Mitigation recommendations
          or other remarks that the expert can understand.";
     }
   }   }

   *  The mitigation request should include a description of the attack
      details, such as the type and characteristics of the attack.  This
      will help the mitigator to identify the attack related to the
      mitigation request and decide whether to respond to the mitigation
      request.  The attack characteristics can also serve as the basis
      for formulating mitigation strategies.  The mitigator can develop
      reasonable mitigation strategies based on the specific features of
      the attack, such as the port, packet-level characteristics, etc.
      Furthermore, by utilizing statistical features of the attack, such
      as peak packet rate, the mitigator can allocate appropriate
      mitigation resources.

   *  In a mitigation request, it is optional to include the target's
      daily business baseline information, such as normal business ports
      and average packet length.  This can assist the mitigator in
      comparing the differences between the normal baseline and attack
      characteristics, thus allowing them to select appropriate
      mitigation strategies.

Cui & Li                  Expires 10 March 2025                 [Page 7]
Internet-Draft      Extended YANG Data Model for DOTS     September 2024

   *  A request to be cached may selectively carry cache relief
      information, including specific cache relief strategies and
      recommendations.  Cache relief strategies are policies already
      installed on the server by the client in advance, while cache
      relief recommendations can be any potentially effective cache
      relief strategy or important information proposed by the client.
      Cache relief information can assist the cache relief party in
      devising appropriate cache relief strategies.

3.2.  Extended YANG models for data channel

   module: ietf-dots-extended-data-channel
    +--rw dots-data
       +--rw mitigation-strategy
       |  +--rw name            string
       |  +--rw type            string
       |  +--rw method          string
       |  +--rw content         string
       +--rw mitigation-capacity
       |  +--rw name            string
       |  +--rw type                  int8
       |  +--rw method                int8
       |  +--rw block-range           string
       |  +--ro filtering-capacity    unit32
       |  +--rw description           string
       +--rw baseline-information
       |  +--ro bps-avg               unit32
       |  +--ro bps-peak              unit32
       |  +--ro pps-avg               unit32
       |  +--ro pps-peak              unit32
       |  +--ro bkts-avg              unit32
       |  +--ro bkts-peak             unit32
       |  +--rw port-range            [lower-port]
       |  |  +--rw lower-port         inet:port-number
       |  |  +--rw upper-port?        inet:port-number
       |  +--rw packet-length-range
       |  |  +--rw min-length         unit32
       |  |  +--rw max-length         unit32
       +--rw intelligence
       |  +--rw type                  string
       |  +--rw content               string
       +--rw mitigation-capabilities
       |  +--rw type                  string
       |  +--rw capacity              string

   Figure 2: DOTS Extended Data Channel Tree Structure

Cui & Li                  Expires 10 March 2025                 [Page 8]
Internet-Draft      Extended YANG Data Model for DOTS     September 2024

   file "ietf-dots-extended-data-channel@2024-02-20.yang" module ietf-
   dots-extended-data-channel { yang-version 1.0; namespace
   "urn:ietf:params:xml:ns:yang:ietf-dots-extended-data-channel";

   grouping mitigation-strategy {
     description
        "Mitigation strategy that clients can install on servers.";
      leaf name {
        type string;
        description
          "Name of the mitigation strategy.";
      }
      leaf type {
       tye enumeration {
         enum block {
           value 1;
           description
             "Discard all DDoS defense methods from specific sources.";
         }
         enum filter {
           value 2;
           description
             "Network devices such as routers
              are used to identify and filter attack traffic.";
         }
         enum scrubbing {
           value 3;
           description
             "Perform refined attack traffic
             filtering with dedicated DDoS scrubbing products.";
         }
       }
      }
      leaf method {
        type string;
        description
          "The name of the specific mitigation
          method used, such as the speed limit.";
      }
      leaf content {
        type string;
        description
          "Specific mitigation directives,
          such as ACL or BGP Flowspec directives.";
      }
   }

   grouping mitigation-capacity {

Cui & Li                  Expires 10 March 2025                 [Page 9]
Internet-Draft      Extended YANG Data Model for DOTS     September 2024

     description
        "Mitigation capacity that servers can offer.";
      leaf name {
        type string;
        description
          "Name of the mitigation resource.";
      }
      leaf type {
       tye enumeration {
         enum block {
           value 1;
           description
             "Discard all DDoS defense methods from specific sources.";
         }
         enum filter {
           value 2;
           description
             "Network devices such as routers
             are used to identify and filter attack traffic.";
         }
         enum scrubbing {
           value 3;
           description
             "Perform refined attack traffic filtering
             with dedicated DDoS scrubbing products.";
         }
       }
      }
      leaf method {
        type string;
        description
          "The name of the specific mitigation
          method used, such as the speed limit.";
      }
      leaf block-range {
        type string;
        description
          "The range that can be blocked when traffic is blocked.";
      }
      leaf filtering-capacity {
        type int32;
        description
          "Filter or clean the maximum acceptable attack traffic rate.";
      }
      leaf description {
        type string;
        description
          "Other supplementary notes.";

Cui & Li                  Expires 10 March 2025                [Page 10]
Internet-Draft      Extended YANG Data Model for DOTS     September 2024

      }
   }

   grouping mitigation-capacity {
     description
        "Describes the mitigation capabilities of
        server-connected Minigators.";
        leaf bps-avg {
        type inet32;
        description
          "Average bps.";
      }
      leaf bps-peak {
        type inet32;
        description
          "Peak bps.";
      }
      leaf pps-avg {
        type inet32;
        description
          "Average pps.";
      }
      leaf pps-avg {
        type inet32;
        description
          "Peak pps.";
      }
      leaf kbps-avg {
        type inet32;
        description
          "Average kbps.";
      }
      leaf kbps-avg {
        type inet32;
        description
          "Peak kbps.";
      }
      leaf port-range {
        key "lower-port";
        description
          "Port range.  When only 'lower-port' is
           present, it represents a single port number.";
        leaf lower-port {
          type inet:port-number;
          description
            "Lower port number of the port range.";
        }
        leaf upper-port {

Cui & Li                  Expires 10 March 2025                [Page 11]
Internet-Draft      Extended YANG Data Model for DOTS     September 2024

          type inet:port-number;
          must '. >= ../lower-port' {
            error-message
              "The upper port number must be greater than
               or equal to the lower port number.";
          }
          description
            "Upper port number of the port range.";
        }
      }
      leaf packet-length-range {
        key "lower-packet-length";
        description
          "Packet length range.  When only 'min-length' is
           present, it represents an avarage length.";
        leaf min-length {
          type int32;
          description
            "Minimum length of the packets.";
        }
        leaf max-length  {
          type int32;
          must '. >= ../min-length' {
            error-message
              "The minium length must be smaller than maximum length.";
          }
          description
            "Maximum length of the packets.";
        }
      }
   }

   grouping intelligence {
      description
        "Threat intelligence, such as IP and URI blacklist,
        botnet activity information, etc.";
      leaf type {
        type string;
        description
            "Types of threat intelligence.";
      }
      leaf type {
        type content;
        description
            "The specifics of the threat intelligence.";
      }
    }

Cui & Li                  Expires 10 March 2025                [Page 12]
Internet-Draft      Extended YANG Data Model for DOTS     September 2024

   }

   *  The data channel should support pre-deployed mitigation strategies
      for clients to choose from in case of attacks, as clients have a
      better understanding of the protection target's business model.
      Through the data channel, it is also important to proactively
      share information about mitigation resources, including available
      mitigation strategies and capacities provided by mitigation
      parties.

4.  IANA Considerations

   This document includes no request to IANA.

5.  Normative References

   [RFC8612]  Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
              Threat Signaling (DOTS) Requirements", RFC 8612,
              DOI 10.17487/RFC8612, May 2019,
              <https://www.rfc-editor.org/rfc/rfc8612>.

   [RFC4732]  Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
              Denial-of-Service Considerations", RFC 4732,
              DOI 10.17487/RFC4732, December 2006,
              <https://www.rfc-editor.org/rfc/rfc4732>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

Acknowledgements

Authors' Addresses

   Yong Cui
   Tsinghua University
   Beijing, 100084
   China
   Email: cuiyong@tsinghua.edu.cn
   URI:   http://www.cuiyong.net/

Cui & Li                  Expires 10 March 2025                [Page 13]
Internet-Draft      Extended YANG Data Model for DOTS     September 2024

   Linzhe Li
   Zhongguancun Laboratory
   Beijing, 100094
   China
   Email: lilz@zgclab.edu.cn

Cui & Li                  Expires 10 March 2025                [Page 14]