Internet-Draft SADA September 2022
Cui, et al. Expires 13 March 2023 [Page]
Workgroup:
SAVNET Working Group
Internet-Draft:
draft-cui-sada-00
Published:
Intended Status:
Informational
Expires:
Authors:
Y. Cui
Tsinghua University
J. Wu
Tsinghua University
L. Hui
Zhongguancun Laboratory
L. Zhang
Zhongguancun Laboratory

SAVNET-based Anti-DDoS Architecture

Abstract

This document proposes the SAVNET-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 (SAV) technique of SAVNET and introducing the data plane and the control plane, the SADA makes minor changes to the SAVNET 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 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 13 March 2023.

Table of Contents

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 attackers.

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 SAVNET-based Anti-DDoS Architecture (SADA) that incorporates the following advances.

The SADA can provide considerable advantages for DDoS attacks by fully adopting SAVNET 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 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 SAVNET-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", "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.

2. Architecture

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

    Figure 1: The SAVNET-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.

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 stages.

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

            +-------------------------------+
+-------+   |  +-------+         +-------+  |  +-------+
| 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 Communications

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.

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 controller.

5. Incentives for Deployment

6. IANA Considerations

This document includes no request to IANA.

7. Security Considerations

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, , <https://www.rfc-editor.org/info/rfc3704>.
[RFC8704]
Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, , <https://www.rfc-editor.org/info/rfc8704>.
[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, , <https://www.rfc-editor.org/info/rfc5210>.
[RFC4987]
Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, , <https://www.rfc-editor.org/info/rfc4987>.
[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, , <https://www.rfc-editor.org/info/rfc8519>.
[RFC5635]
Kumari, W. and D. McPherson, "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", RFC 5635, DOI 10.17487/RFC5635, , <https://www.rfc-editor.org/info/rfc5635>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

8.2. Informative References

[SAVNET_WG]
"Source Address Validation in Intra-domain and Inter-domain Networks", , <https://datatracker.ietf.org/doc/charter-ietf-savnet/>.
[DOTS_WG]
"DDoS Open Threat Signaling (dots)", , <https://datatracker.ietf.org/doc/charter-ietf-dots/>.

Acknowledgements

TBD

Authors' Addresses

Yong Cui
Tsinghua University
Beijing, 100084
China
Jianping Wu
Tsinghua University
Beijing, 100084
China
Linbo Hui
Zhongguancun Laboratory
Beijing, 100094
China
Lei Zhang
Zhongguancun Laboratory
Beijing, 100094
China