Internet DRAFT - draft-cheng-savnet-proactive-defense-network
draft-cheng-savnet-proactive-defense-network
Network Working Group W. Cheng
Internet-Draft China Mobile
Intended status: Informational N. Geng
Expires: 7 September 2023 Huawei
D. Li
Tsinghua University
C. Zheng
China Mobile
6 March 2023
Network Proactive Defense based on Source Address Validation
draft-cheng-savnet-proactive-defense-network-00
Abstract
Network proactive defense can be achieved if the routers run source
address validation mechanisms for checking the validity of packets.
This document mainly describes network proactive threat awareness
which can be the first step of network proactive defense.
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.
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 7 September 2023.
Cheng, et al. Expires 7 September 2023 [Page 1]
Internet-Draft Network Proactive Defense March 2023
Copyright Notice
Copyright (c) 2023 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
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
2. Network Proactive Threat Awareness Architecture . . . . . . . 3
3. Use Cases of Network Proactive Threat Awareness . . . . . . . 5
3.1. Security Situational Awareness . . . . . . . . . . . . . 5
3.2. Security Services for Customers . . . . . . . . . . . . . 5
3.3. Attack Source Tracing . . . . . . . . . . . . . . . . . . 6
3.4. Entire Network Security Planning . . . . . . . . . . . . 6
4. Requirements for Networks . . . . . . . . . . . . . . . . . . 6
5. Deployment Considerations for Proactive Defense Network . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Source address spoofing is one of the important security threats to
the Internet. Many attacks, such as flood-based DoS, reflective
attacks and spoof-based worm/malware propagation [RFC6959][netscout],
are based on spoofed source addresses. These attacks harm both ISPs'
and customers' networks. The ISPs' bandwidth may be drained, which
impacts customers' services. Some malicious traffic can traverse the
ISP network and directly attack the customer network. The attacks
bring great economic losses to both ISPs and customers. Besides,
spoofed source addresses make it hard to tracing the attackers. ISPs
have the requirement to detect the threats of source address spoofing
throughout the networks so that they can better defend themselves and
guarantee the services.
Cheng, et al. Expires 7 September 2023 [Page 2]
Internet-Draft Network Proactive Defense March 2023
To meet the threat awareness requirement, firewalls, DPI devices, or
anti-DDoS systems can be deployed at the IDC entrance or the trunk
interface to sense and intercept attack traffic including source
address spoofing traffic. However, the requirement of ISPs cannot be
fully met. These methods are single-point ones which are lack of
network-level view. Threats are usually identified through big data
analysis, which inevitably brings challenges to recall, accuracy, and
timeliness, and makes source tracing difficult. Since routers are
not directly involved in defending networks, the methods can only
provide out-of-band reactive threat awareness.
Route-based source address validation (SAV)
[RFC2827][RFC3704][RFC8704] enables network routers to detect source
address spoofing attacks. The SAV mechanisms can help routers
configure or generate SAV rules which indicate the valid incoming
interfaces of source addresses. When a packet arrives, the validity
of the packet will be checked by the rules. The router with SAV
rules installed can validate packets locally without the assistance
of an external device. Any router in the network (mostly edge
routers and aggregation routers) can conduct packet validation
[manrs-antispoofing][nist-rec] and detect packets with spoofed source
addresses in a real-time manner.
By deploying SAV, the network can have the capability of proactive
defense, which is named as proactive defense network in this
document. In a proactive defense network, routers can directly
identify threats through SAV. The proactive threat awareness feature
is much helpful for satisfying the threat awareness requirement of
ISPs.
To efficiently discover threats and inform operators, routers need to
automatically generate accurate SAV rules for validation and report
threat information in real time to the security analysis center for
further analysis [sav-table]. The threats reported by routers can be
treated as a complementary to the previously mentioned single-point
methods. Together with the single-point methods, network proactive
threat awareness based on SAV can help ISPs obtain more accurate
threat awareness results at the entire network level.
This document mainly describes network proactive threat awareness
which can be the first step of network proactive defense.
2. Network Proactive Threat Awareness Architecture
This section shows how SAV help ISPs achieve network proactive threat
awareness. Figure 1 presents the architecture based on SAV. In the
architecture, the security analysis center is connected to the
routers that deploy SAV in the local network.
Cheng, et al. Expires 7 September 2023 [Page 3]
Internet-Draft Network Proactive Defense March 2023
At the beginning, the routers need to get SAV rules installed in
advance. The SAV mechanisms can be enabled on routers to generate
SAV rules automatically. The rules can also be configured manually.
The accuracy of SAV rules will affect that whether threats can be
detected or omitted. In some cases, operators can install some
tentative SAV rules whose accuracy cannot be guaranteed. The
tentative rules can be used for monitoring the packets with the
particular source addresses and usually take a conservative action to
invalid packets (e.g., only sampling but not dropping).
The packets passing through the router will be checked. If the check
result is invalid or unknown, the router samples the packets and
reports them to the center. At the same time, the router records the
validation statistics, e.g., the total number of invalid packets
received from an interface. These statistics can also be reported.
It should be noted that the router may choose to directly take
further actions (e.g., dropping, permitting, rate limiting, etc.) on
the packet with invalid validation or wait for further instructions
from the center. It's up to the configurations of operators.
The center collects and analyzes the threat data reported by the
routers. The data may be consolidated with those from other data
sources (e.g., anti-DDoS devices) to provide a global view on network
threats. Based on this view, further filtering operations can be
performed. The architecture supports a closed-loop security
protection workflow consisting of threat awareness, threat analysis,
and threat elimination as shown in Figure 1.
+-------------------+
| Security Analysis | Step2: threat analysis
| Center |
+--#-----#--------#-+
Step1: report / | \ Step3: threat elimination
threat data / | ... \ instructions
+-------------/--------|-----------\--------------+
| AS / | \ |
| +--------#--+ +-----#-----+ ... +#----------+ |
| |SAV Router1| |SAV Router2| ... |SAV RouterN| |
| +-----------+ +-----------+ ... +-----------+ |
+-------------------------------------------------+
Figure 1: Network proactive threat awareness architecture
The architecture works without requiring the full deployment of SAV
on routers. Even only partial routers enable SAV at the particular
interfaces, network proactive threat awareness can still take effect
and provides valuable threat data for the security analysis center.
Besides, this architecture has some tolerance for the accuracy of SAV
Cheng, et al. Expires 7 September 2023 [Page 4]
Internet-Draft Network Proactive Defense March 2023
rules. Different SAV mechanisms have different application scenarios
and are constantly evolving. In some special scenarios, such as
asymmetric routing, route convergence, and failure scenarios, the SAV
accuracy cannot be guaranteed. Even so, network proactive threat
awareness can still detect the existence of potential/ongoing
threats. Overall, the architecture has no strict requirements for
SAV deployment and accuracy guarantees of SAV rules. The incomplete
and flawed threat data can still provide important reference for the
security analysis center. By consolidating the threat data from
network proactive threat awareness and other threat awareness tools,
the center can have a good view of network security situation.
Although the SAV deployment and accuracy guarantees are not strictly
required, there are some requirements on the networks. The
requirements ensure that the architecture works normally or is fully
utilized for threat awareness. See Section 4 for more details of
these requirements.
3. Use Cases of Network Proactive Threat Awareness
This section will introduce some SAV use cases for network proactive
threat awareness.
3.1. Security Situational Awareness
Network routers can proactively and quickly detect attack packets
with spoofed source addresses and report the threat data to the
security analysis center. The center can obtain interface/router-
based statistics and the sampled data packets. These data are
helpful for operators understanding the current situation of network
security and visualizing network threats.
Compared with only relying on single-point and reactive defense
methods, ISPs can get more accurate, complete, and real-time threat
information by using network proactive threat awareness. The
information will greatly help ISPs better defend their networks.
3.2. Security Services for Customers
The threat awareness capability of the network enables the ISP to
fully understand the source address spoofing attacks on the network.
Therefore, when an attack occurs, the ISP can provide warnings for
the customer network to help customers better cope with the attack
traffic. In addition, ISPs can provide customers with the services
of attack traffic blocking/rate-limiting and provide different
service levels. Customers can choose to purchase the appropriate
service. When an ISP detects the attack to a customer, the ISP
preferentially allocates some network resources to the customer who
Cheng, et al. Expires 7 September 2023 [Page 5]
Internet-Draft Network Proactive Defense March 2023
purchase services and intercepts attack traffic at the upstream
routers. Such security services can help reduce the impact of
attacks on customers' networks, which also enhances ISPs'
competitiveness.
3.3. Attack Source Tracing
The threat information can be used to locate the attack's entrance to
the local threat awareness network, i.e., attack source tracing. O&M
and troubleshooting costs are reduced. Besides, the ISP can carry
out near source filtering on the entrance router interface which is
the closest point to the attack source in the network. Near source
filtering blocks attack traffic as soon as possible and thus
minimizes the effects of the attack to the network.
3.4. Entire Network Security Planning
Network proactive threat awareness can help ISPs learn which types of
attacks are predominant, from which directions are more frequent, and
which target networks are frequently attacked. This kind of
information provides reference for entire network security planning.
For example, security analysis center can pre-install tentative rules
for monitoring/blocking/limiting/redirecting the particular traffic,
so that the attack traffic can be properly processed immediately.
4. Requirements for Networks
The networks for proactive threat awareness need to meet the
following requirements:
* Network routers SHOULD be able to automatically generate accurate
SAV rules to form a complete SAV table. Besides, the rule
generation mechanism SHOULD cover various scenarios including
single-homing subnets/ASes, multi-homing subnets/ASes, internal
aggregation points, the Internet interfaces, etc.
* Interface-based source prefix allowlists are preferred as SAV
rules, under which the validation is strict and unknown prefixes
are blocked. When such allowlists are hard to be obtained (e.g.,
at the Internet interfaces), interface-based source prefix
blocklists or prefix-based interface allowlists SHOULD be
generated as SAV rules which focus on checking specific prefixes
and ignore unknown prefixes [sav-table].
Cheng, et al. Expires 7 September 2023 [Page 6]
Internet-Draft Network Proactive Defense March 2023
* A tool SHOULD be provided to implement remote configuration of SAV
rules. Unlike sRTBH [RFC5635], the configured rules SHOULD affect
only the packets from the specified prefix, not the packets
destined for the specified prefix. So, only relying on FIB for
SAV like uRPF-based sRTBH is not enough. There may be an
independent SAV table in the data plane for validating packets.
* Routers can check packets with spoofed source addresses in real
time based on the SAV table and proactively report statistics and
packet information. Various actions, such as sampling, rate
limiting, discarding, and traffic redirecting, SHOULD be supported
for packets with different validation results [sav-table].
5. Deployment Considerations for Proactive Defense Network
ISPs are very careful when deploying SAV. There exist risks that SAV
may cause network interruption and negative impacts on the customers'
networks. Therefore, the phased deployment is likely to be adopted.
Gradually enabling SAV for threat awareness and elimination can be
much helpful for ISPs to reduce the risks of network incidents. The
following shows a possible strategy of the phased deployment.
* Phase 1: Only focus on threat awareness by enabling SAV on
specified interfaces. Threat elimination actions will be seldom
taken.
* Phase 2: Support threat awareness by enabling SAV on all important
interfaces, and routers can take threat elimination actions
explicitly instructed by operators or the security analysis
center.
* Phase 3: Taking on threat awareness by fully enabling SAV in the
network, and routers can take threat elimination actions directly
(e.g., dropping or rate limiting invalid packets directly). The
routers will also coordinate with the security analysis center for
achieving an automatic proactive defense system.
6. IANA Considerations
This document makes no request of IANA.
7. Security Considerations
TBD
Cheng, et al. Expires 7 September 2023 [Page 7]
Internet-Draft Network Proactive Defense March 2023
8. Acknowledgements
TBD
9. References
9.1. Normative References
[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/info/rfc2119>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[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,
<https://www.rfc-editor.org/info/rfc5635>.
[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/info/rfc8174>.
[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,
<https://www.rfc-editor.org/info/rfc8704>.
[sav-table]
"Source Address Validation Table Abstraction and
Application", 2022, <https://datatracker.ietf.org/doc/
draft-huang-savnet-sav-table/>.
9.2. Informative References
[manrs-antispoofing]
MANRS, "MANRS Implementation Guide", 2023,
<https://www.manrs.org/netops/guide/antispoofing/>.
Cheng, et al. Expires 7 September 2023 [Page 8]
Internet-Draft Network Proactive Defense March 2023
[netscout] NETSCOUT, "DDoS THREAT INTELLIGENCE REPORT", 2023,
<https://www.netscout.com/threatreport>.
[nist-rec] Sriram, K. and D. Montgomery, "Resilient Interdomain
Traffic Exchange: BGP Security and DDos Mitigation", 2019,
<https://www.nist.gov/publications/resilient-interdomain-
traffic-exchange-bgp-security-and-ddos-mitigation>.
[RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address
Validation Improvement (SAVI) Threat Scope", RFC 6959,
DOI 10.17487/RFC6959, May 2013,
<https://www.rfc-editor.org/info/rfc6959>.
Authors' Addresses
Weiqiang Cheng
China Mobile
Beijing
China
Email: chengweiqiang@chinamobile.com
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Ce Zheng
China Mobile
Beijing
China
Email: zhengce@chinamobile.com
Cheng, et al. Expires 7 September 2023 [Page 9]
