<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-cheng-savnet-proactive-defense-network-03" category="info" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.23.2 -->
  <front>
    <title abbrev="Network Proactive Defense">Network Proactive Defense based on Source Address Validation</title>
    <seriesInfo name="Internet-Draft" value="draft-cheng-savnet-proactive-defense-network-03"/>
    <author initials="W." surname="Cheng" fullname="Weiqiang Cheng">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>chengweiqiang@chinamobile.com</email>
      </address>
    </author>
    <author initials="N." surname="Geng" fullname="Nan Geng">
      <organization>Huawei</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>gengnan@huawei.com</email>
      </address>
    </author>
    <author initials="D." surname="Li" fullname="Dan Li">
      <organization>Tsinghua University</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>tolidan@tsinghua.edu.cn</email>
      </address>
    </author>
    <author initials="S." surname="Yue" fullname="Shengnan Yue">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>yueshengnan@chinamobile.com</email>
      </address>
    </author>
    <author initials="M." surname="Huang" fullname="Mingqing Huang">
      <organization>Zhongguancun Laboratory</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>huangmq@mail.zgclab.edu.cn</email>
      </address>
    </author>
    <date year="2024" month="October" day="20"/>
    <area>rtg</area>
    <workgroup>savnet</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 84?>
<t>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.</t>
    </abstract>
  </front>
  <middle>
    <?line 87?>

<section anchor="sec-intro">
      <name>Introduction</name>
      <t>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 <xref target="RFC6959"/><xref target="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.</t>
      <t>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.</t>
      <t>Route-based source address validation (SAV) <xref target="RFC2827"/><xref target="RFC3704"/><xref target="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 <xref target="manrs-antispoofing"/><xref target="nist-rec"/> and detect packets with spoofed source addresses in a real-time manner.</t>
      <t>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.</t>
      <t>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 <xref target="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.</t>
      <t>This document describes the PDN architecture as well as the use cases, requirements, and deployment considerations.</t>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

</section>
    </section>
    <section anchor="proactive-defense-network-architecture">
      <name>Proactive Defense Network Architecture</name>
      <t><xref target="fig-pdn-arch"/> 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.</t>
      <t>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 <xref target="I-D.li-savnet-sav-yang"/>.</t>
      <t>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.</t>
      <t>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 <xref target="I-D.li-savnet-sav-yang"/> or BGP FlowSpec <xref target="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 <xref target="fig-pdn-arch"/>.</t>
      <figure anchor="fig-pdn-arch">
        <name>Network proactive threat awareness architecture</name>
        <artwork><![CDATA[
              +---------------------+
              | Controller/Security | Step2: threat analysis
              | Analysis Center     |
              +--#-----#--------#---+
Step1: report   /      |         \ Step3: threat elimination
threat data    /       |   ...    \ instructions
+-------------/--------|-----------\--------------+
| AS         /         |            \             |
| +--------#--+ +-----#-----+  ...  +#----------+ |
| |SAV Router1| |SAV Router2|  ...  |SAV RouterN| |
| +-----------+ +-----------+  ...  +-----------+ |
+-------------------------------------------------+
]]></artwork>
      </figure>
      <t>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.</t>
      <t>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).</t>
      <t>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.</t>
      <t>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 <xref target="sec-requirement"/> for more details of these requirements.</t>
    </section>
    <section anchor="use-cases">
      <name>Use Cases</name>
      <t>This section will introduce some SAV use cases for proactive defense network architecture.</t>
      <section anchor="security-situational-awareness">
        <name>Security Situational Awareness</name>
        <t>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.</t>
        <t>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.</t>
      </section>
      <section anchor="security-services-for-customers">
        <name>Security Services for Customers</name>
        <t>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.</t>
      </section>
      <section anchor="attack-source-tracing">
        <name>Attack Source Tracing</name>
        <t>The threat information can be used to locate the attack's entrance to the local threat awareness network, i.e., attack source tracing. O&amp;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.</t>
      </section>
      <section anchor="path-protection-for-important-traffic">
        <name>Path Protection for Important Traffic</name>
        <t>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.</t>
      </section>
      <section anchor="accurate-sav-rule-generation">
        <name>Accurate SAV Rule Generation</name>
        <t>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.</t>
      </section>
      <section anchor="entire-network-security-planning">
        <name>Entire Network Security Planning</name>
        <t>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.</t>
      </section>
    </section>
    <section anchor="sec-requirement">
      <name>Requirements</name>
      <t>The networks for proactive defense network need to meet the following requirements:</t>
      <ul spacing="normal">
        <li>
          <t>Complete SAV rule generation capability. Network routers <bcp14>SHOULD</bcp14> 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 <bcp14>SHOULD</bcp14> cover various scenarios including single-homing subnets/ASes, multi-homing subnets/ASes, internal aggregation points, the Internet interfaces, etc.</t>
        </li>
        <li>
          <t>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.</t>
        </li>
        <li>
          <t>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 <bcp14>SHOULD</bcp14> be generated as SAV rules which focus on checking specific prefixes and ignore unknown prefixes <xref target="I-D.huang-savnet-sav-table"/>.</t>
        </li>
        <li>
          <t>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, <bcp14>SHOULD</bcp14> be supported for packets with different validation results <xref target="I-D.huang-savnet-sav-table"/>.</t>
        </li>
      </ul>
    </section>
    <section anchor="deployment-considerations">
      <name>Deployment Considerations</name>
      <t>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.</t>
      <ul spacing="normal">
        <li>
          <t>Phase 1: Only focus on threat awareness by enabling SAV on specified interfaces. Threat elimination actions will be seldom taken.</t>
        </li>
        <li>
          <t>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.</t>
        </li>
        <li>
          <t>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.</t>
        </li>
      </ul>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document makes no request of IANA.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>There is no new security consideration introduced.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Much thanks for the contributions from: Ce Zheng.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC3704" target="https://www.rfc-editor.org/info/rfc3704" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3704.xml">
          <front>
            <title>Ingress Filtering for Multihomed Networks</title>
            <author fullname="F. Baker" initials="F." surname="Baker"/>
            <author fullname="P. Savola" initials="P." surname="Savola"/>
            <date month="March" year="2004"/>
            <abstract>
              <t>BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="84"/>
          <seriesInfo name="RFC" value="3704"/>
          <seriesInfo name="DOI" value="10.17487/RFC3704"/>
        </reference>
        <reference anchor="RFC2827" target="https://www.rfc-editor.org/info/rfc2827" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2827.xml">
          <front>
            <title>Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing</title>
            <author fullname="P. Ferguson" initials="P." surname="Ferguson"/>
            <author fullname="D. Senie" initials="D." surname="Senie"/>
            <date month="May" year="2000"/>
            <abstract>
              <t>This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="38"/>
          <seriesInfo name="RFC" value="2827"/>
          <seriesInfo name="DOI" value="10.17487/RFC2827"/>
        </reference>
        <reference anchor="RFC8704" target="https://www.rfc-editor.org/info/rfc8704" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8704.xml">
          <front>
            <title>Enhanced Feasible-Path Unicast Reverse Path Forwarding</title>
            <author fullname="K. Sriram" initials="K." surname="Sriram"/>
            <author fullname="D. Montgomery" initials="D." surname="Montgomery"/>
            <author fullname="J. Haas" initials="J." surname="Haas"/>
            <date month="February" year="2020"/>
            <abstract>
              <t>This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="84"/>
          <seriesInfo name="RFC" value="8704"/>
          <seriesInfo name="DOI" value="10.17487/RFC8704"/>
        </reference>
        <reference anchor="RFC6959" target="https://www.rfc-editor.org/info/rfc6959" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6959.xml">
          <front>
            <title>Source Address Validation Improvement (SAVI) Threat Scope</title>
            <author fullname="D. McPherson" initials="D." surname="McPherson"/>
            <author fullname="F. Baker" initials="F." surname="Baker"/>
            <author fullname="J. Halpern" initials="J." surname="Halpern"/>
            <date month="May" year="2013"/>
            <abstract>
              <t>The Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6959"/>
          <seriesInfo name="DOI" value="10.17487/RFC6959"/>
        </reference>
        <reference anchor="I-D.geng-idr-flowspec-sav" target="https://datatracker.ietf.org/doc/html/draft-geng-idr-flowspec-sav-04" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.geng-idr-flowspec-sav.xml">
          <front>
            <title>BGP Flow Specification for Source Address Validation</title>
            <author fullname="Nan Geng" initials="N." surname="Geng">
              <organization>Huawei</organization>
            </author>
            <author fullname="Dan Li" initials="D." surname="Li">
              <organization>Tsinghua University</organization>
            </author>
            <author fullname="tongtian124" initials="" surname="tongtian124">
              <organization>China Unicom</organization>
            </author>
            <author fullname="Mingqing(Michael) Huang" initials="M." surname="Huang">
              <organization>Zhongguancun Laboratory</organization>
            </author>
            <date day="12" month="October" year="2024"/>
            <abstract>
              <t>BGP FlowSpec reuses BGP route to distribute infrastructure and propagates traffic flow information with filtering actions. This document proposes some extensions to BGP FlowSpec for disseminating SAV rules.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-geng-idr-flowspec-sav-04"/>
        </reference>
        <reference anchor="I-D.huang-savnet-sav-table" target="https://datatracker.ietf.org/doc/html/draft-huang-savnet-sav-table-07" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.huang-savnet-sav-table.xml">
          <front>
            <title>General Source Address Validation Capabilities</title>
            <author fullname="Mingqing(Michael) Huang" initials="M." surname="Huang">
              <organization>Zhongguancun Laboratory</organization>
            </author>
            <author fullname="Weiqiang Cheng" initials="W." surname="Cheng">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Dan Li" initials="D." surname="Li">
              <organization>Tsinghua University</organization>
            </author>
            <author fullname="Nan Geng" initials="N." surname="Geng">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Mingxing Liu" initials="" surname="Liu">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Li Chen" initials="L." surname="Chen">
              <organization>Zhongguancun Laboratory</organization>
            </author>
            <author fullname="Changwang Lin" initials="C." surname="Lin">
              <organization>New H3C Technologies</organization>
            </author>
            <date day="25" month="August" year="2024"/>
            <abstract>
              <t>The SAV rules of existing source address validation (SAV) mechanisms, are derived from other core data structures, e.g., FIB-based uRPF, which are not dedicatedly designed for source filtering. Therefore there are some limitations related to deployable scenarios and traffic handling policies. To overcome these limitations, this document introduces the general SAV capabilities from data plane perspective. How to implement the capabilities and how to generate SAV rules are not in the scope of this document.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-huang-savnet-sav-table-07"/>
        </reference>
        <reference anchor="I-D.li-savnet-sav-yang" target="https://datatracker.ietf.org/doc/html/draft-li-savnet-sav-yang-05" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.li-savnet-sav-yang.xml">
          <front>
            <title>YANG Data Model for Intra-domain and Inter-domain Source Address Validation (SAVNET)</title>
            <author fullname="Dan Li" initials="D." surname="Li">
              <organization>Tsinghua University</organization>
            </author>
            <author fullname="Fang Gao" initials="F." surname="Gao">
              <organization>Zhongguancun Laboratory</organization>
            </author>
            <author fullname="Changwang Lin" initials="C." surname="Lin">
              <organization>New H3C Technologies</organization>
            </author>
            <author fullname="Jianping Wu" initials="J." surname="Wu">
              <organization>Tsinghua University</organization>
            </author>
            <author fullname="Tianhao Wu" initials="T." surname="Wu">
              <organization>Huawei</organization>
            </author>
            <author fullname="Weiqiang Cheng" initials="W." surname="Cheng">
              <organization>China Mobile</organization>
            </author>
            <date day="3" month="September" year="2024"/>
            <abstract>
              <t>This document describes a YANG data model for Intra-domain and Inter-domain Source Address Validation (SAVNET). The model serves as a base framework for configuring and managing an SAV subsystem, including SAV rule and SAV Tables, and expected to be augmented by other SAV technology models accordingly. Additionally, this document also specifies the model for the SAV Static application.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-li-savnet-sav-yang-05"/>
        </reference>
        <reference anchor="netscout" target="https://www.netscout.com/threatreport">
          <front>
            <title>DDoS THREAT INTELLIGENCE REPORT</title>
            <author>
              <organization/>
            </author>
            <date year="2023" month="January"/>
          </front>
        </reference>
        <reference anchor="manrs-antispoofing" target="https://www.manrs.org/netops/guide/antispoofing">
          <front>
            <title>MANRS Implementation Guide</title>
            <author>
              <organization/>
            </author>
            <date year="2023" month="January"/>
          </front>
        </reference>
        <reference anchor="nist-rec" target="https://www.nist.gov/publications/resilient-interdomain-traffic-exchange-bgp-security-and-ddos-mitigation">
          <front>
            <title>Resilient Interdomain Traffic Exchange - BGP Security and DDos Mitigation</title>
            <author>
              <organization/>
            </author>
            <date year="2019" month="January"/>
          </front>
        </reference>
      </references>
    </references>
    <?line 218?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA7Vbe3Pbxnb/H59ia880cU1QlpM2Cef23siSbGvGklVJSSb3
8QcILMmtQCyDBSQzsvNZ+ln6yXpe+wBJyfK01UxiAgR2z57n7zyY53nWma7W
E3Wmu1vbXqvz1hZlZ260OtIz3TitpoXTlbKNurR9W2p1UFWtdk79XNSmKjpj
m6yYTlt988AiWWXLpljCPlVbzLq8XOhmnrviptFdvvJP5xU/nTe8Tv7im8xO
na11p90k61ewHX7AfyZZCf+f23Y9UaaZ2cz106VxDsi5Wq9go5Pjq9dZZlbt
RHVt77qXL1788OJlVrS6mKi2m2e4w7y1/WqimJDsWq/hZgXvNp1ukbQjpDbL
ir5b2HaSqTxTsJubqF/G6hDPANd8rl+0+c0UzTzctu28aMzvxKAJ3DVNoU7t
1NQavtTLwtQTRWy4lTd/LPGZJT0yLu0SHitNB8d7pc1/GlqztH3T4YlpuYSc
s7F6k1JzVjT+xpCOt30B+0UK5vBQUzQ/Luj+l257NFbvTNj0CDaly+GWVw5W
gfXVTw3IuHWweNy/s6hEzY+dPDTWVT8umy8h4nKsfu11oOJywUeSm48Rw7rX
Tt763wjhdIzsTaRwCi/8Bv+F20Ni/rqwzXwOX5U9MK6Y2rboQJ8jXQt8bfnb
j3g1/n1e1sX00fzJGtsuC7SqCVgBGEi4Uuri9eE33734Vj6+/P7ld/Lx+3j3
33741x/w40l+NEYlyU3V5rPa3rqVLtFy/ZdEpDdl+Cfvimmt/be1Sb9aw6P4
DVw7oLfDz0qJBzo6spfq6u3F8cGVOjm7On737uTN8dnhsbo4Pn9/cUWPiiEq
ugBuksuhpegOOQb18sXLb/IX+7x20c51B6zsupWb7O3d3t6O/e4o371uAQ6h
a/XKtrjGsmhalxdNZ9zK2plhegONpwdnF5fqZLmq9VI3HQlSvelNpe8hj174
Atpo/zG8ugdU2pXbm+PieylByD/jurzV5YC2C+1MbYAqdl+VBbVp1BV4sJkp
1fGHcgHc1ypXr96cq0td9i1okCqaCjnvQFk7M2d3fg+nTy6vBifZ/+FBLgON
47m92Vv109qUtLLbaz2RuYlE5h0TmWshMp/OV7kTEkEaVV5V1uXLSGI2Ho+z
LM9zVUwdvF52mYSnQsLTTQhP6uvLg5+fqYWuV06Bw4d9Hbre8lp1C80PIivs
TK2K8hq0Y+wjGTwHnqSHKIhPwjJwvSrAOeDznVW6AXpL/Ba1SBW3EF4a2H2s
rhbGKYh6PeqJghC3sk47FWKdklinJNap24VudSQPtq0MiLir1wo0AOQ/W8s2
Dv+1/XyBBOFOOll2kxI1g8seVgZykAOzvlbgDCDkgUbN1uid8Ghbr7X6tx72
J+qBMSeX53Ao5vjSVBW4z+wpKlprq74kLt89BYmhWFv7aVMYXneRCttoXBF3
NUs0O1Bu5YUdj2jpCR+Jx+q0aEBbuw4k5EbK9eVCFXC62toqZ4gC/mMEdM9q
zayQh0nFiQB5Dti93FsWNZ6VJFOwUqm/id/7x92d9xGfPo0UPhZAEC0EH93g
gJokrl3cdFG0SzW13YJY9xURUQIMsUsQ71de6vyaPDKFZ25NBa8si7WaasRK
ptHVCHTDwHGBWyBkly7jdHtjStz9Eu7Ae2BpxvbAPjF71CP4jHGXdRi2CiqH
NAUlY8LpGb+Bf5CJ9CebtijIOemLLm1jl7BPbZEJKLVw5uGRxxCqHCgyyu4e
FgL516ATHfKuIgUAu/YKyrvTQrT4orjhA6WKCu9UgBXLLtFph8rm7lFHMSQQ
NL3hpQLPw3VBN9fEw6nuQBHZaCu8vXS6vtF8SIjhLSixZoKCTLLsyqql1t1n
LWykZvDptqhrYM/R+QnsQ0uMwPMq9P05BUe3dh1sLATBQ6varoGRTKg6OToE
hwRMQ48EL9Kubd9cK/K1swIdlQX60O0g3XS71KsuCF+0xjRl3VfIoHsZx0+C
S3hrbzWo12hLGOI1kNrGdkgw+B5QtCVaMxsLfFzYypGFIQCsdb6yBt8FDonW
43c1Egfr+byghh1rdWP0La7EUsbnetcXdXSYRlfBVU7NHANXAQcv6rUzLlhV
A7xGzLJmzcbQAIsA5GF9BvOAS/ACJXioolyPiHWdWeraoBz5GlXXeW55va0M
8qiv4bzZpUGpePeOxCJTootvbizoE8pElAwX8PrIzPXcQvHbBl4C33UDR1Ww
aE7eDQgBZuwOBOi9L3B78YLuM+Hy7k6w4adP9BERo3z8nj6CriHSc8Gd+MNF
K7xPe8SVsF/BqLrUGPiNE+XGQBVDoW1mZo4hDHQaoKgGmMxvtX0d1MQAxzAj
jCEdtRh8EwYdr/47fAH6zl8A/KtCgj/IpgX+Cc9TcIDX8sytqWvUaEIRwMzp
mtUfCeJTMfXwYLdIaIU8oUPlquiYwnO/qgMvWpL+4lveJxWQ08JLZNMz0DWl
P2BILGpxEmN1AIFRtgPtSfyY+nppHWqXruaJ7oGWFHPw3xL15P4zIgmYjfHc
nzPRiru7bWyM+uCxKCgExROWvD8Rnf9eh2+Q7aCmdY72hOAbpIuK+mot3g3F
B+wbDY5FKuL9fwLIEMBt4qtg5o6SsgpBw/0g7Ovzo7NnzMUEvkHIQULhu9H/
L0BbIqr5P0BpEHc0uh4E2kBeZQDLgI8O5LHzx5xQ2ZWmtNPFozVaU/iFFMBi
0sg6GSyPHeHABJHURFXYDyG08xSHBBS+Be6iyMmFepjnYjrC3lmVGo2WVp71
LTzTxu/u7u5PPD99Yob7ozIdbKKp7KbopuEJ1ogCFD8kde3ak7VqwcQATlHU
apB61OI0UIlPBqZfWUiBFt7k6VA7HhwFVXtAI2LFjRIO8YcUTO20w6xuadtE
EDvUwkHUcR4YIOltVHKOnigkWpdQFy2IWNiDHIQIhOtZoQbZDKC4sjVTjI+w
OpgF+MxyYdDwUZGBn7ca/GPB32P2VMKJUMOiukrcZCunVcH1IEBsi7Dr06eQ
1MY31DsQeF/MNdKj1TVAMyzXOfXk9KfLqycj/ledvafPF8f/8dPJxfERfr58
e/DuXfiQyROXb9//9O4ofopvHr4/PT0+O+KX4a4a3MqenB78+oTpf/L+/Ork
/dnBuydbXoOCPAJizQEIlIm1LfP8o2j/6vD8v/9r/1tQ6n/CgLu//wN4Ur74
fv87jLOQGTa8G0V9vkRkmhWrlS7I64OJoicEIIMQEjjvFvYWFafVgEP/5W/I
mX9M1J+m5Wr/2z/LDTzw4Kbn2eAm8Wz7ztbLzMQdt3ZsE7g5uL/B6SG9B78O
rj3fk5t/+gsiMpXvf/+XP2eYnm7Xsn2B+iDR1yy7uwOAka+qJkc9Bo6DqBxp
nGT9Apnujxup/lO0oMid3OQABioO2THE/xaxzL1OzxDoaeBNdsTdIkZvSkvY
asg9SMQn5BDztSw7YNOf6rlpGnBEo8Eq3sWDy9qJTlCjqhsEHfditKkWAEie
KsF+OyDaIJIIPqIvcCHQWDKSgPMQTTcM5H0chRtg95Lj2RqQkgGn9evB2RsJ
Btt1RgwE7Cg8FlkhlIpJX8KQTTwHImS4x1UidqcoFoDpBC1BepBXNWBiKV8h
XGMQcQlSdEkwpPtLL1CWNaA3FhS8qikkDhYEfEEeLkBRDqEOK48O+Am2rsfz
Mb/T2Q51oF9OUb9mgVhPCSymDeYYs9YuEUkGXOzzsbjuQDI+horkfESldAqf
S7FGDFWVfUSsA0536Kv6usKdICeinE0Cl3AByyHlwlpH/jSgrg4DVwAHHKzU
18yPCkLZitQeItrSdB19JrWsDdYR8VJ35fgZau8A2XeLwLmE5SDx28J0A0CC
9tL2sjExNRXsSfeVU/0qyFvUm8MbyidAL6+oYv4leohSVId8w++iU8I9YnwK
bBLTZhnRE1JFwrhqOdGoPDhBVhLBlg5CjzM6DxyMZQcpRjzDk/iUs1Dz2k4L
TsKRhV7UgrvG6pUHMRQU8bFRYNzM1EAr2iLzgDgiTgVuIFbEsheePzoRaf9t
+gxMVyIXSiqA1J6V3tQ/4ylQulgVf13b28uVLuXRnX0PDzAHkMf1K7ZwMIga
mFvltbWr6OGBbfgoKhJyCddjvOM64sJsyzBG4U6oV1DdgW9qVOJG0LYP9gaT
tGEkQ836448/qEgf/57nu/6ebzz1UR2GcLUX+gUf1WWnVy8nm+RtvXzgg9oh
i4LubhPylPZ+6ol4SoTgFvsTn0MotecX9X9/Jyq+mezgR5YaSXyXXh6Px/x2
arnZkB17/sPH5ObfN1kF57sM1OyFT5FC2mbAEXgn7ATHfC5XfPTnQtzzp8ku
9M5HtAAq3LT7g6uXH+Wd5N7Zx+E+edwnH+6TD/fZrRIP/T0nxbqbqKepynEz
6t+fnH0+y0kN6Mkn9oADo+JSrK+FcO7gM2EsJabJA1gQciEikbE6vtG+Tla0
nQGn4EEK4xZ6QQINPVH2NYFpXyx6VK6G3giMGKihcAShEMsfaKriKqm01tOG
qWbOpEB7HwikKoivmJMLHfBmgVZvKYEG86TqkF/RFyo9T6QodWSAtBZ5tQHm
qJJShW8hp/DtOuWAlqI1VkJRy8EEGzZYVMKKJciD8C7Rgi4S+Rxei32awq2X
kAK3piQpcDRGceCKN7oFV1tqdnGzwtTkU+MqvvkWjhZryqH2XonEnf1CuSUd
A/0BHLKWUtsKXHaDerNnm7kV4MixDXW11cBwIDlEcVpSILTIhlvEN8NqpXX6
cwehAkZ4OULlKWXTFYl6aRsD23qDGBTcNlR6q+6GbPa1clLbggSr2xvekcEU
xvtNDCnggMyK0C7XV4cPTcFcqbotIOwZKvN7kDIV0jdTI9LlxoI0QDu6QY2A
Doq8SyydNNGzLzDNbWg7cpDqvyscHmK9qotbXQ2MMCqBxzWxIwnyRYNIDOt+
U321TlDWRrGOrR2x1iO0kpJ8gkhbX1HeM0oQZiyDAhizthIoFrokkV5nup4M
mhLDGv2ppD+P5K1vV7CIQPQipIrowZIP2iuq/EB6dlCN9oXx9AlIolEDAuDf
4f9pjgUV1VJizD0k8CC1+V0sYTunuNQaoBC2o5PdAOax3bSYv3fgZZxU9d2Q
Kio9qZ/g7iGWrbj45Tx8Q20x0veWQyMXQ5WLNnlspYBqXAFbXXo5gQ898KfJ
zjbaKyj2sH7NExxAfHmNlV72ZdLOe1wRflCtHartZ6qzLNBEG6U6GULoHtPs
O04xu2QoqyVhllQyDF9wMsrdOvQPSUE8etu+qYAbYKqVNzggkiJYUPedxoBb
3xh0fub3pMeWOPfsENxG0fpsiXxdC5wmpN4My7qDlpuXdaj1+v4n1VkGNduR
8r5p5NeQJsiOijnkNr1LaX0on2bPF18mhaVu/SA732pomzYx1A29lI42SeDQ
d/SzWGYfxNW0HZN2bXy70E8hgHKJMQdJsk483DTc8Cp0YB+Lb6mR13j9t8hs
8Zm4o1gOOXoguKFur/fum0MPSB+xK4wweJ6VoIQxzg5b59wqqiqDvE8UwG8b
F4ttAs9dbO8N+/DT2pbXQOUeqkzuCxcpukyAm6zD5X2QYRAUN/ZC/WQF7IWQ
y90zQHsQpFuDhRFZwPdDG+IZexQ3OKpFvCCrR+6uJGIiZEK3VGNNstOCU0OT
WPs6g6+LeL4DMoq0BaYM5hTcJoMkbPQrh82cZQT/l4g7YwD0q8Xmsib3LUNI
YEyR+6RhO0Z1fCeRag8y+OVkdAeNWUPqAybpe+1gQAdMrMxCXfFUQGo2qZ2m
+A5Yw8xL2P6Vi8Mdwjou+m6ZoBA8UmassZDDVAxnE8bq/T+fshsGnqFdgn6Q
cpXWyTQF86hKJndSQyqLtl3j6AHsFzFmUtlpfO+JaQ4daj+KEvqypAVYNXGd
Yq8q5xtSbjbs/mzntmQy23qCWsi1kpV1zmA2xv6md2ppGrAsX2PjDM5Dg0Tn
B5uTfM8LMOHzWNpBV3ISAKRMXj4wl0gGzbuGWQWubvoS4Waw9jooyoKm3hZz
UghaTLMLBUJAGygwrpBGOYvnBqFRStbwSuyRUKykLxRRASBZDIIxd4nZ9egB
hIO0SXKCDlnQrJYh0UCEn0pzvtOK0/847rZJfbCmtO98AQThhLtUDzP/Eb3j
dn9a2FWE0R5au7WgBssYXYsQk7lnDmAXMhluR8Dq3HPoL85fc5C9v30jBeUH
OcShhSu91GIChEEV2tQnSNNeR5N+oAs/El/JCSi1GsCWBt2jrwRo1UWj/Ywq
VhYUBJkKtUTKpwSt/cJ+TySIkc2GFm42z2EdSqRZnSMbh3UHkeox96Y9yA2Y
4xxoxACdnX+ejRRla3AHjRDWrVdpPGV3BipWoY0VNG+HJsAPJxaHjxFMm2E+
QIN5yFNZlPU3zAgWyXNhfpKzd+Cp52gqzlARGuaWG+35WDQWFozVa3zqA2Hl
0f16xzhD50EFNioIw6rBXgAXHlfsAYOYF6GmEEoIYrWjdDJy08n6Aj5NEfB4
WoleC5RyuYSlCzQsTq4GbX0eHE4zNS4GBk4/nFH5XmaYtJyBVdlbPESa1U1w
elkd+orALu2O2DUMgIesS1rZqO5UyvuS8RhEujhrEx0MfUnzKmN1QKm9b4L5
zoboCp3MeOuCAy1tt9FLGlQ+BvIRvdg1KkWlHVKTPe6rsJvYcPMboX/bG4gx
e+7wlNENVu0grsbqYTJPysnTgoOd66c4aL13cIlbLPu6M7u/ItSAaXE6uEZY
waMSmRMflG+xv0dSD6GDRsFBYKH+S0fSH7Dh76hAcuS7ixwTXp+8CkWo4P9p
mMx2YLhUSMHvC8jq9c0g/CSBXiJCdL4g9cN3khZH7BL8w4aw0JFtalVCNNXb
eLzRmXmDQZ1G6umcvILEOkkPcb6aht+xQ+jNB3TOrjoCQnQtLa248+d4N1A9
bzaPioWDWTWuYOzIynP1uoa4grsnrF3aiiYuROrD4VZMScwHSkVua+NxLScq
LU9+JeGT8lDv7IcNdywAcXmSSqfc+pflpT5G7hTdP2VPXPce7uvH2pHTVCgB
CnyztbtPi5+N4sXOw9G+vAm5SbwpD0asnVASHZl3WUM+CANmFlIgyoRwBIIs
0gPGeGzEG/MGA+YWSz43o8fOWNwYwXGJwcAgPxdbxZLQRVL84qGMR0+YxmHD
aWxJJx7Yp9OhoCbFsI1ylcwHJPF8rH4WTye0x3aHL41vjRzgKCZjW+nnSuxM
Qu8oEZEYoRQ6B0eOiX+ip37w7/PchyB8FAu/h4PZuyzj32+AXMGfY5MCpNrX
XF4ZzOVK9YXxnmqNu5YJJcJ6OLZR9Imxk0K2/SpMiTbky290+G2LCOe+X8r4
Qg/5lAWJMylfG54LqtdiZUUFHg1N8k1bVNztoCKUEL+zeExkpe11QTVbo7nE
Ivp9QKgk8PmToiPEPRoNFr8bgQk27BF3h2QUf8PW6XmcM9883FhJ7xzs5pxK
JPsT9R5Lk8FSt+dIN85LP18iI06dg/O/oRhOFYg5+skop+sKB1yKa92w9TIV
LyfqUiLFY/ZHXBp7LGmwpipoYuXUl9o17iCEQeDBHzvxjye4m89jILFE/IgW
qz/GNxN1VVyHusX2QbhUOTjOsCDx5ScIg0wbM0tI98BtbDXY/JvP0t8aiKwI
QJbWopPBRZI64wMz1gl+aSKy3RG3+TdIjOJPDs4ONl3HcFKYfxbTWELiWN/B
IXV4i98Pyd7WGprn4RscIbuNlA9GhGMXpuLlDkqMQTX+2IEQf3baUyQvmuuk
zIszLZiQhqGtiTrU6q/4+2/yi3meQ6AorzP5+x+sLD9nJEEAAA==

-->

</rfc>
