savnet W. Cheng Internet-Draft China Mobile Intended status: Informational N. Geng Expires: 23 April 2025 Huawei D. Li Tsinghua University S. Yue China Mobile M. Huang Zhongguancun Laboratory 20 October 2024 Network Proactive Defense based on Source Address Validation draft-cheng-savnet-proactive-defense-network-03 Abstract Source address validation (SAV) helps routers check the validity of packets. Networks can use the SAV capability to enhance threat awareness. This document proposes proactive defense network where routers can directly identify threats through SAV. The proactive threat awareness feature is helpful for satisfying the threat awareness requirement of ISPs. 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 23 April 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Cheng, et al. Expires 23 April 2025 [Page 1] Internet-Draft Network Proactive Defense October 2024 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Proactive Defense Network Architecture . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Security Situational Awareness . . . . . . . . . . . . . 6 3.2. Security Services for Customers . . . . . . . . . . . . . 6 3.3. Attack Source Tracing . . . . . . . . . . . . . . . . . . 6 3.4. Path Protection for Important Traffic . . . . . . . . . . 7 3.5. Accurate SAV Rule Generation . . . . . . . . . . . . . . 7 3.6. Entire Network Security Planning . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 23 April 2025 [Page 2] Internet-Draft Network Proactive Defense October 2024 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 (PDN) in this document. In a PDN, 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 [I-D.huang-savnet-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 and help make more proper defense actions. This document describes the PDN architecture as well as the use cases, requirements, and deployment considerations. Cheng, et al. Expires 23 April 2025 [Page 3] Internet-Draft Network Proactive Defense October 2024 1.1. 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. Proactive Defense Network Architecture Figure 1 presents the SAV-based proactive defense network architecture. In the architecture, the controller or security analysis center is connected to the routers that deploy SAV in the local network. 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 through management tools like YANG [I-D.li-savnet-sav-yang]. 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. The reported data can efficiently help ISPs do network proactive threat awareness. 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, and SAV rules updates can also be conducted by the central center through YANG [I-D.li-savnet-sav-yang] or BGP FlowSpec [I-D.geng-idr-flowspec-sav]. The architecture supports a closed-loop security protection workflow consisting of threat awareness, threat analysis, and threat elimination as shown in Figure 1. Cheng, et al. Expires 23 April 2025 [Page 4] Internet-Draft Network Proactive Defense October 2024 +---------------------+ | Controller/Security | Step2: threat analysis | 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 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. Therefore, 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 invalid packets but not dropping). 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. Cheng, et al. Expires 23 April 2025 [Page 5] Internet-Draft Network Proactive Defense October 2024 3. Use Cases This section will introduce some SAV use cases for proactive defense network architecture. 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 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. Cheng, et al. Expires 23 April 2025 [Page 6] Internet-Draft Network Proactive Defense October 2024 3.4. Path Protection for Important Traffic Source address validation limits the incoming directions of source addresses, which can be leverage to limited the forwarding path of the traffic from specific sources. By installing tailored SAV rules on routers, proactive defense network can monitor whether the target traffic traverses the pre-defined forwarding paths. 3.5. Accurate SAV Rule Generation Generating accurate SAV rules can be a challenging problem by using a completely distributed manner like uRPF. The security analysis center in the proactive defense network can help collect SAV-related information over the network, generate accurate SAV rules, and install them into the routers' data planes. This is a kind of centralized SAV rule generation method, which can be a complementary of existing distributed SAV mechanisms. 3.6. Entire Network Security Planning Proactive defense network 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 The networks for proactive defense network need to meet the following requirements: * Complete SAV rule generation capability. Network routers SHOULD be able to automatically generate accurate SAV rules to form a complete SAV table. A tool should also be provided to implement remote configuration of SAV rules so that the center have the capability to install/update the rules on routers. 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. Cheng, et al. Expires 23 April 2025 [Page 7] Internet-Draft Network Proactive Defense October 2024 * Accurate and scalable SAV rule expression. Directly using FIB for SAV like uRPF is not enough for achieving accurate validation in the data plane. ACL-based filtering provides the capability of accurate SAV rule expression but faces significant scalability problems. The hardware may need to be optimized to support accurate and scalable SAV rule expression so that the routers in the proactive defense network can efficiently detect network threats. * Flexible validation mode. 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 [I-D.huang-savnet-sav-table]. * Configurable actions to validated 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 [I-D.huang-savnet-sav-table]. 5. Deployment Considerations 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. Cheng, et al. Expires 23 April 2025 [Page 8] Internet-Draft Network Proactive Defense October 2024 * 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 There is no new security consideration introduced. 8. Acknowledgements Much thanks for the contributions from: Ce Zheng. 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [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, . [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, . Cheng, et al. Expires 23 April 2025 [Page 9] Internet-Draft Network Proactive Defense October 2024 [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address Validation Improvement (SAVI) Threat Scope", RFC 6959, DOI 10.17487/RFC6959, May 2013, . [I-D.geng-idr-flowspec-sav] Geng, N., Li, D., tongtian124, and M. Huang, "BGP Flow Specification for Source Address Validation", Work in Progress, Internet-Draft, draft-geng-idr-flowspec-sav-04, 12 October 2024, . [I-D.huang-savnet-sav-table] Huang, M., Cheng, W., Li, D., Geng, N., Liu, Chen, L., and C. Lin, "General Source Address Validation Capabilities", Work in Progress, Internet-Draft, draft-huang-savnet-sav- table-07, 25 August 2024, . [I-D.li-savnet-sav-yang] Li, D., Gao, F., Lin, C., Wu, J., Wu, T., and W. Cheng, "YANG Data Model for Intra-domain and Inter-domain Source Address Validation (SAVNET)", Work in Progress, Internet- Draft, draft-li-savnet-sav-yang-05, 3 September 2024, . [netscout] "DDoS THREAT INTELLIGENCE REPORT", January 2023, . [manrs-antispoofing] "MANRS Implementation Guide", January 2023, . [nist-rec] "Resilient Interdomain Traffic Exchange - BGP Security and DDos Mitigation", January 2019, . Authors' Addresses Weiqiang Cheng China Mobile Beijing China Email: chengweiqiang@chinamobile.com Cheng, et al. Expires 23 April 2025 [Page 10] Internet-Draft Network Proactive Defense October 2024 Nan Geng Huawei Beijing China Email: gengnan@huawei.com Dan Li Tsinghua University Beijing China Email: tolidan@tsinghua.edu.cn Shengnan Yue China Mobile Beijing China Email: yueshengnan@chinamobile.com Mingqing Huang Zhongguancun Laboratory Beijing China Email: huangmq@mail.zgclab.edu.cn Cheng, et al. Expires 23 April 2025 [Page 11]