Skip to main content

SAVA-based Anti-DDoS Architecture

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Yong Cui , Jianping Wu , Linbo Hui , Lei Zhang
Last updated 2022-09-12
RFC stream (None)
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)
SAVNET Working Group                                              Y. Cui
Internet-Draft                                                     J. Wu
Intended status: Informational                       Tsinghua University
Expires: 17 March 2023                                            L. Hui
                                                                L. Zhang
                                                 Zhongguancun Laboratory
                                                       13 September 2022

                   SAVA-based Anti-DDoS Architecture


   This document proposes the SAVA-based Anti-DDoS Architecture (SADA),
   which can efficiently detect, mitigate, and traceback Denial-of-
   Service (DDoS) attacks that spoof source addresses.  The SADA
   consists of a distributed DDoS detection mechanism based on
   honeynets, a multi-stage DDoS mitigation mechanism, and a suspect-
   based DDoS traceback mechanism.  By adopting the Source Address
   Validation Architecture (SAVA) of SAVNET and introducing the data
   plane and the control plane, the SADA makes minor changes to the SAVA
   while providing major benefits.

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

   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 17 March 2023.

Copyright Notice

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

Cui, et al.               Expires 17 March 2023                 [Page 1]
Internet-Draft                    SADA                    September 2022

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (
   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
   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Distributed DDoS Detection Mechanism Based on
           Honeynets . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Multi-stage DDoS Mitigation Mechanism . . . . . . . . . .   6
     2.3.  Suspect-based DDoS Traceback Mechanism  . . . . . . . . .   6
     2.4.  Connection Example  . . . . . . . . . . . . . . . . . . .   6
     2.5.  Establish and Keep Communication  . . . . . . . . . . . .   7
   3.  Data Plane  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Control Plane . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Incentives for Deployment . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   DDoS attacks using spoofing addresses are notorious on the Internet.
   The attackers command a large number of zombie hosts to forge the
   target's address and send bogus requests, after which the servers
   respond with magnified datagrams to the target, resulting in an
   amplification DDoS attacks.  Some other DDoS attacks (e.g., TCP SYN
   Flooding Attacks [RFC4987]) also forge source IP addresses in order
   to drain the target's resources.  These DDoS attacks are simple to
   carry out but can inflict significant damage.  Their attack traffic
   is widely dispersed and similar to normal traffic, leading challenge
   to detect and mitigate.  Furthermore, the spoofed addresses serve as
   a mask for the attackers, making it difficult to traceback the

Cui, et al.               Expires 17 March 2023                 [Page 2]
Internet-Draft                    SADA                    September 2022

   Some Source Address Validation (SAV) techniques have been proposed to
   defend against DDoS attacks.  The current practice for achieving
   ingress filtering is uRPF [RFC3704], which includes strict uRPF and
   loose uRPF.  Unfortunately, the strict uRPF often improperly blocks
   legitimate traffic under asymmetric routing, and the loose uRPF
   generally permits all received packets.  EFP-uRPF [RFC8704] makes the
   uRPF more flexible about directionality, while there are mechanisms
   that MAY lead to improper permit or improper block problems in
   specific scenarios.  The SAVNET Working Group [SAVNET_WG] provides
   SAV techniques for intra-domain and inter-domain networks to resolve
   the problems raised above.  It has been deployed for experimental
   practice [RFC5210] and is promising to solve the SAV problem.

   However, these SAV techniques are still a long way from being able to
   defend against DDoS attacks.  First, they only discard spoofing
   packets at local devices, lacking coordination to detect DDoS attacks
   with a global view.  Second, only when these SAV techniques are
   widely deployed will they be able to eliminate DDoS attacks using
   spoofing addresses, which will take a long time.  Third, there are
   limited incentives exist to encourage Internet Service Providers
   (ISPs) to widely deploy SAV devices.

   In the above context, this document offers a SAVA-based Anti-DDoS
   Architecture (SADA) that incorporates the following advances.

   *  A distributed DDoS detection mechanism based on honeynets.  The
      SADA introduces a SAV controller for gathering spoofing statistics
      from SAV routers that act as honeynets.  The SADA can detect DDoS
      attacks with a comprehensive analysis using aggregated information
      from distributed SAV routers.

   *  A multi-stage DDoS mitigation mechanism.  By overviewing the DDoS
      attack with a comprehensive view, the mitigation policies can be
      deployed at multiple stages (i.e., near-source, middle, and near-
      target).  These policies vary at different locations and can
      efficiently mitigate the attack.

   *  A suspect-based DDoS traceback mechanism.  The SADA requires SAV
      routers to monitor the communication logs of suspicious hosts that
      have ever forged addresses.  The communication logs will be
      analyzed to find the attackers.

   The SADA can provide considerable advantages for DDoS attacks by
   fully adopting SAVA features with only minor changes.  Even with a
   small number of SAV routers deployed, the SADA can deliver accurate
   DDoS detections across a larger area.  As long as the attack traffic
   flows through the SAV domain, the SADA is able to mitigate it.  With
   the aggregated communication logs of suspicious hosts, the SADA can

Cui, et al.               Expires 17 March 2023                 [Page 3]
Internet-Draft                    SADA                    September 2022

   also assist in tracing back the attacker.  In addition, the SADA will
   provide a spoofing address database and a DDoS attacks database, both
   of which will be available for SAV domains and other domains.  The
   above incentives MAY induce ISPs to widely deploy SAV devices, which
   will, in turn, stimulate a more valuable SADA system.

1.1.  Terminology

   *  SADA: the SAVA-based Anti-DDoS Architecture.

   *  SAV router: a router that can validate source addresses, make
      statistics of suspicious hosts, and execute filtering policies.

   *  SAV controller: a server that communicates with SAV routers.  It
      can detect, mitigate, and traceback DDoS attacks.

   *  SAV device: either a SAV router or a SAV controller.

   *  SAV domain: a network domain that has SAV routers deployed.

   *  suspect: a host that ever forged source addresses in the past is
      considered a suspect, also called a suspicious host.

   *  honeynet: consists of SAV routers that record the spoofing
      packets' statistics instead of always blocking them.

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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.

2.  Architecture

Cui, et al.               Expires 17 March 2023                 [Page 4]
Internet-Draft                    SADA                    September 2022

   |                Control Plane (SAV controller)                 |
   |  +-------------+       +-------------+       +-------------+  |
   |  |  Detection  |       | Mitigation  |       |  Traceback  |  |
   |  +-------------+       +-------------+       +-------------+  |
   |  +--------------------+     +------------------+              |
   |  | Spoofing Addresses |     |   DDoS Attack    |              |
   |  | Database           |     |   Database       |     ...      |
   |  +--------------------+     +------------------+              |
                   |                               |
        Northbound |                               | Southbound
        Interface  |                               | Interface
                   |                               |
   |                  Data Plane (SAV routers)                     |
   |  +-------------+    +-------------+    +-------------+        |
   |  | Monitoring  |    | Measurement |    |  Filtering  |  ...   |
   |  +-------------+    +-------------+    +-------------+        |

       Figure 1: The SAVA-based Anti-DDoS Architecture

   The proposed SADA is shown in Figure 1.  The SADA consists of the
   data plane and the control plane, where the primary functions of the
   data plane are monitoring, measurement, and filtering, and the
   primary functions of the control plane are detecting the attacks,
   formulating defense strategies, and tracing back the attacks.  The
   northbound interface is used to send statistics data to the control
   plane, and the southbound interface is used to receive defense
   strategies from the control plane.  The two planes communicate with
   each other and work together to defend against DDoS attacks.

2.1.  Distributed DDoS Detection Mechanism Based on Honeynets

   The data plane reflects the widely distributed SAV routers that serve
   as the architecture's foundation.  When detecting packets using
   spoofed addresses, the SAV routers do not simply block them but
   record their statistics and behaviors, which is regarded as a
   honeynet.  The SAV routers need periodically transmit the statistics
   data to the SAVA controller.

Cui, et al.               Expires 17 March 2023                 [Page 5]
Internet-Draft                    SADA                    September 2022

   Based on the statistics data aggregated from the data plane, the
   control plane determines whether there is an ongoing DDoS attack.
   The judgment MAY refer to the traffic volume, the number of distinct
   addresses, the protocol, and the port numbers.  A convincing judgment
   results include factors such as the ongoing traffic volume, impacted
   scope, duration time, and so on.

2.2.  Multi-stage DDoS Mitigation Mechanism

   The control plane represents the SAV controller, which is the core of
   the architecture.  With the detailed judgment results, the control
   plane then formulates mitigation strategies for multiple stages.
   From the spatial perspective, the attack traffic can be divided into
   three stages of near-source, middle, and near-target.  Mitigation MAY
   include various filtering mechanisms on SAV routers at different

   After the mitigation strategies validating by the SAV controller, the
   mitigation instructions will be issued to SAV routers.  The near-
   source SAV routers MAY directly filter the spoofed packets using the
   specific forged source address.  The middle SAV routers MAY route the
   spoofed packets of specific target addresses and protocols into
   unreachable destinations.  The near-target SAV routers MAY adopt
   other filtering techniques to block the malicious packets based on
   specific target address, protocol, and packet size.  Such a multi-
   stage mechanism can mitigate the DDoS attack as much as possible.

2.3.  Suspect-based DDoS Traceback Mechanism

   The data plane MUST record the communication logs of the suspicious
   host that forged source addresses in the past.  The communication
   logs include the spoofing packets' IP addresses, port numbers, packet
   amounts, intervals, frequencies, and so on.  These logs will be
   periodically transmitted to the SAV controller for further analysis.

   When DDoS attacks occur, zombie hosts with spoofing addresses are
   potentially communicating with the attackers.  Analyzing the
   communication logs of these suspicious zombie hosts, the SAV
   controller is able to trace back the attacker.

2.4.  Connection Example

Cui, et al.               Expires 17 March 2023                 [Page 6]
Internet-Draft                    SADA                    September 2022

   +-------+   |  +-------+         +-------+  |  +-------+
   | SR 1  +---+  | SC 1  +----+----+ SC 2  |  +--+ SR 3  |
   +-------+   |  +-------+    |    +-------+  |  +-------+
               |               |               |
   +-------+   |           +---+---+           |  +-------+
   | SR 2  +---+           | SC 3  |           +--+ SR 4  |
   +-------+   |           +-------+           |  +-------+
   SR: SAV router
   SC: SAV controller

         Figure 2: Connection Example of SAV Devices

   Figure 2 depicts a connection example of SAV devices.  There are SAV
   routers distributed throughout the network, and they MUST communicate
   with the SAV controller in order to collaborate.  This document
   suggests that each SAV router stores several records of the SAV
   controller for backup.  Each SAV router MUST try to connect to its
   nearest SAV controller at all times.  If the SAV router loses contact
   with the present controller, it MUST seek the next closest
   controller.  Such a mechanism can assist SAV routers in maintaining
   connections to the best of their abilities.

   The SAV controller appears as a single server to the external.
   Realizing the full functionality of the SAV controller, it MAY
   require much computing and storage resources.  As a result, the SAV
   controller can be built as clustered or distributed servers, where
   consistency and scalability are the primary concerns.  Each SAV
   controller can communicate with many SAV routers and perform the
   corresponding functions.

2.5.  Establish and Keep Communication

         +------------+               +------------+
         |   SAV      +---------------> SAV        |
         |   Router   <---------------+ Controller |
         +------------+               +------------+

   Figure 3: SAV Router and SAV Controller Establish and Keep

Cui, et al.               Expires 17 March 2023                 [Page 7]
Internet-Draft                    SADA                    September 2022

   Given the broad deployment of SAV routers, each configured SAV router
   MUST automatically establish connections with a SAV controller.  They
   MUST maintain contact after building connections.  This document
   suggests that an OSPF-like approach be considered.  Furthermore, the
   SAV router MUST be able to communicate with the SAV controller during
   DDoS attacks, and such a mechanism MAY refer to the DOTS Working
   Group [DOTS_WG].

3.  Data Plane

   The data plane is primarily comprised of distributed SAV routers.
   SAV routers MAY be deployed in access networks, within Autonomous
   System (AS) domains, or at the AS domains boundary.  The general
   features of SAV routers are the same wherever they are deployed and
   can be summarized as follows.

   *  Collect Spoofing Information.  SAV routers need to collect the
      statistical data of packets with spoofed addresses.  The
      information includes but is not limited to spoofed source
      addresses, destination addresses, port numbers, packet intervals,
      and frequencies.

   *  Collect information of suspicious hosts.  When SAV routers detect
      a host forging source addresses, they MAY add the host to the list
      of suspicious hosts.  The SAV routers MUST then monitor the
      communication logs of these suspicious hosts.  The logs contain
      information that includes but is not limited to destination
      addresses, protocols, packet intervals, and frequencies.

   *  Receive and Execute Instructions.  When the SAV controller issue
      the defense strategies, the SAV routers MUST respond
      appropriately.  The response mainly consists of Access Control
      Lists (ACL) filtering [RFC8519] and black-hole routing [RFC5635].
      SAV routers with various locations will perform different actions,
      such as filtering spoofed packets at the access network and black-
      hole routing at the AS domain boundary.

   *  Keep the Capacity for Escape.  Attack traffic can sometimes exceed
      router links, resulting in disconnection from SAV routers to the
      SAV controller.  To avoid the terrible circumstance, SAV routers
      MUST reserve a specified amount of bandwidth to maintain a
      continuous connection with the SAV controller.

Cui, et al.               Expires 17 March 2023                 [Page 8]
Internet-Draft                    SADA                    September 2022

4.  Control Plane

   The control plane consists of the SAV controller that can be
   clustered or distributed servers.  The SAV controller are responsible
   for detecting, mitigating, and tracing back DDoS attacks.  They also
   provide spoofing address database and DDoS attacks database for
   others to reference.  The following are the features of the SAV

   *  Aggregate Spoofing Information.  The SAV controller collects
      spoofing statistics from SAV routers everywhere and aggregates
      them for further analysis.

   *  Detect DDoS Attacks.  The SAV controller MUST determine whether a
      DDoS attack is ongoing based on the aggregated information.  The
      judgment results MUST specify the attack target, traffic volume,
      impacted scope, duration time, and so on.

   *  Formulate Defense Strategies.  Based on judgment results, the SAV
      controller will devise the appropriate defense strategies.  The
      defense mechanisms MAY include ACL-based filtering and black-hole
      routing, which vary on specific SAV routers according to their
      locations.  The SAV controller then issues detailed defense
      instructions to individual SAV routers for execution.

   *  traceback Attacks.  The SAV controller also aggregates information
      about suspicious hosts and analyzes the communication logs of
      these suspicious hosts to locate the attacker.

   *  Build and Maintain the databases.  The SAV controller MUST build
      and maintain the spoofing address database at a global view, which
      will, in turn, help to detect DDoS attacks.  The SAV controller
      MUST also build the DDoS attack database with the detection
      results, which contain the details about each attack, such as the
      attacker address, the target address, traffic volume, impacted
      scope, and duration time.  Such a DDoS attack database will help
      to review the entire process of attacks.

   *  Provide Management Interface.  Detecting, mitigating, and tracing
      back DDoS attacks MAY necessitate some manual settings in certain
      contexts.  The management interface provides a convenient way to
      adjust these settings.

5.  Incentives for Deployment

   *  Provide DDoS Defense Ability.  Whenever the attack traffic flows
      through the SAV domains, the SAV devices can react to mitigate the
      attack.  Any ISP that has deployed SAV devices can also obtain the

Cui, et al.               Expires 17 March 2023                 [Page 9]
Internet-Draft                    SADA                    September 2022

      spoofing address information and DDoS attacks information.  With
      this accurate and real-time information, ISPs can decide how to
      take measures to protect their customers.

   *  Locate the Malicious Hosts and Reduce Costs.  With deployed SAV
      devices, ISPs can identify the zombie hosts and help to traceback
      the attackers.  These zombie hosts MAY incur additional traffic
      and energy costs.  Locating and removing these malicious hosts not
      only help to reduce the costs but also improve the reputation of

6.  IANA Considerations

   This document includes no request to IANA.

7.  Security Considerations

   *  When DDoS attacks appear, the SAV routers MAY perform different
      filtering policies at different locations.  If SAV routers get a
      bogus mitigation policy, they MAY undertake destructive filtering

   *  The SAV controller is the core of the SADA and MUST be secure at
      all times.  The SAV controller SHOULD be able to defend themselves
      against any invasions.

   *  The SAV controller's functions are based on statistical data
      aggregated from the SAV routers.  Fake statistical data might have
      unanticipated consequences.

8.  References

8.1.  Normative References

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
              2004, <>.

   [RFC8704]  Sriram, K., Montgomery, D., and J. Haas, "Enhanced
              Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
              RFC 8704, DOI 10.17487/RFC8704, February 2020,

   [RFC5210]  Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams,
              "A Source Address Validation Architecture (SAVA) Testbed
              and Deployment Experience", RFC 5210,
              DOI 10.17487/RFC5210, June 2008,

Cui, et al.               Expires 17 March 2023                [Page 10]
Internet-Draft                    SADA                    September 2022

   [RFC4987]  Eddy, W., "TCP SYN Flooding Attacks and Common
              Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,

   [RFC8519]  Jethanandani, M., Agarwal, S., Huang, L., and D. Blair,
              "YANG Data Model for Network Access Control Lists (ACLs)",
              RFC 8519, DOI 10.17487/RFC8519, March 2019,

   [RFC5635]  Kumari, W. and D. McPherson, "Remote Triggered Black Hole
              Filtering with Unicast Reverse Path Forwarding (uRPF)",
              RFC 5635, DOI 10.17487/RFC5635, August 2009,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

8.2.  Informative References

              "Source Address Validation in Intra-domain and Inter-
              domain Networks", June 2022,

   [DOTS_WG]  "DDoS Open Threat Signaling (dots)", March 2022,



Authors' Addresses

   Yong Cui
   Tsinghua University
   Beijing, 100084

Cui, et al.               Expires 17 March 2023                [Page 11]
Internet-Draft                    SADA                    September 2022

   Jianping Wu
   Tsinghua University
   Beijing, 100084

   Linbo Hui
   Zhongguancun Laboratory
   Beijing, 100094

   Lei Zhang
   Zhongguancun Laboratory
   Beijing, 100094

Cui, et al.               Expires 17 March 2023                [Page 12]