BMWG L. Chen Internet-Draft Zhongguancun Laboratory Intended status: Informational D. Li Expires: 18 March 2027 Tsinghua University L. Liu L. Qin Zhongguancun Laboratory 14 September 2026 Benchmarking Methodology for Intra-domain and Inter-domain Source Address Validation draft-ietf-bmwg-savnet-sav-benchmarking-04 Abstract This document defines methodologies for benchmarking the performance of intra-domain and inter-domain source address validation (SAV) mechanisms. SAV mechanisms are utilized to generate SAV rules that prevent source address spoofing. The methodology treats a SAV device as a black box and is therefore agnostic to the specific SAV mechanism and implementation used by the device. This document defines test setups, performance indicators, and test cases for SAV accuracy, control-plane and data-plane performance, and resource utilization. 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 18 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Chen, et al. Expires 18 March 2027 [Page 1] Internet-Draft SAV Benchmarking Methodology September 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Goal and Scope . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Test Methodology . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Network Topology and Device Configuration . . . . . . . . 7 4. SAV Performance Indicators . . . . . . . . . . . . . . . . . 8 4.1. False Positive Rate . . . . . . . . . . . . . . . . . . . 8 4.2. False Negative Rate . . . . . . . . . . . . . . . . . . . 8 4.3. Protocol Convergence Time . . . . . . . . . . . . . . . . 8 4.4. Protocol Message Processing Throughput . . . . . . . . . 9 4.5. Data Plane SAV Table Refreshing Rate . . . . . . . . . . 9 4.6. Data Plane Forwarding Rate . . . . . . . . . . . . . . . 9 4.7. Resource Utilization . . . . . . . . . . . . . . . . . . 9 5. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . 9 5.1. Intra-domain SAV . . . . . . . . . . . . . . . . . . . . 9 5.1.1. False Positive and False Negative Rates . . . . . . . 9 5.1.2. Control Plane Performance . . . . . . . . . . . . . . 14 5.1.3. Data Plane Performance . . . . . . . . . . . . . . . 15 5.2. Inter-domain SAV . . . . . . . . . . . . . . . . . . . . 17 5.2.1. False Positive and False Negative Rates . . . . . . . 17 5.2.2. Control Plane Performance . . . . . . . . . . . . . . 34 5.2.3. Data Plane Performance . . . . . . . . . . . . . . . 34 5.3. Resource Utilization . . . . . . . . . . . . . . . . . . 34 6. Reporting Format . . . . . . . . . . . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 9. Normative References . . . . . . . . . . . . . . . . . . . . 36 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37 Appendix A. Summary of Changes (to be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . . . . . . 37 A.1. Changes from Version -03 to Version -04 . . . . . . . . . 37 A.2. Changes from Version -02 to Version -03 . . . . . . . . . 38 A.3. Changes from Version -01 to Version -02 . . . . . . . . . 38 A.4. Changes from Version -00 to Version -01 . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Chen, et al. Expires 18 March 2027 [Page 2] Internet-Draft SAV Benchmarking Methodology September 2026 1. Introduction Source address validation (SAV) is a fundamental mechanism for mitigating IP source address spoofing [RFC2827] [RFC3704] [RFC8704]. Operators may deploy SAV at different locations, including access networks, intra-domain interfaces, and inter-domain interfaces [RFC5210]. Existing intra-domain and inter-domain SAV mechanisms can suffer from improper blocks, improper permits, and operational overhead in several deployment scenarios [I-D.ietf-savnet-intra-domain-problem-statement] [I-D.ietf-savnet-inter-domain-problem-statement]. The SAVNET Working Group has analyzed the problem space for both intra-domain and inter-domain SAV. Intra-domain SAV is applied at external interfaces on routers facing entities that are not deployed as neighboring ASes, such as a single host, a set of hosts, or a customer network with no AS. SAV on traffic received on external interfaces facing a neighboring AS is considered inter-domain SAV, regardless of whether the neighboring AS uses a public or private ASN. SAV on internal interfaces between routers in the same AS is outside the scope of the intra-domain SAV benchmarking scenarios in this document. This document uses the same conceptual split when defining benchmarking test cases. This document provides generic methodologies for benchmarking SAV mechanism performance. A SAV device may support one or more SAV mechanisms, and operators may enable different mechanisms depending on their network environments. This document treats the Device Under Test (DUT) as a black box and does not assume a particular implementation. The tests defined in this document can be used to benchmark SAV accuracy, protocol convergence performance, control- plane processing performance, data-plane SAV table refresh performance, data-plane forwarding performance, and resource utilization. These tests can be performed on a hardware router, software router, virtual machine (VM), or container instance that runs as a SAV device. 1.1. Goal and Scope The benchmarking methodology outlined in this document has two goals: * Benchmark SAV mechanisms and implementations over a set of well- defined intra-domain and inter-domain scenarios. * Measure the contribution of control-plane, data-plane, and resource-related sub-systems to the overall performance of a SAV device. Chen, et al. Expires 18 March 2027 [Page 3] Internet-Draft SAV Benchmarking Methodology September 2026 This document focuses on laboratory benchmarking of individual DUTs. It does not define a new SAV mechanism, protocol extension, or operational recommendation. The test cases are intended to evaluate whether a DUT can produce correct SAV behavior and maintain acceptable performance under representative scenarios. 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. Terminology This document uses the terminology in [I-D.ietf-savnet-intra-domain-problem-statement] and [I-D.ietf-savnet-inter-domain-problem-statement]. The following terms are used in this document. SAV Device: A device that applies SAV to incoming packets. In this document, the SAV device is the DUT. SAV Control Plane: The processes used to gather, communicate, compute, and update information used for SAV rule or SAV table generation. SAV Data Plane: The packet-processing component that validates each incoming packet against the applicable SAV rules and either permits or blocks the packet. SAV Rule: A rule that indicates the validity of a specific source IP address or source IP prefix per router interface. It is used by a router to make SAV decisions. SAV Table: The table of prefixes that indicates the validity of a specific source IP address or source IP prefix per interface. A SAV table contains the information used by the DUT to make SAV decisions. The terms "SAV rules" and "SAV table" describe individual validation rules and their collective table, respectively. Proper Block: The validation result in which packets with spoofed source addresses are blocked by the DUT. Proper Permit: The validation result in which packets with legitimate source addresses are permitted by the DUT. Chen, et al. Expires 18 March 2027 [Page 4] Internet-Draft SAV Benchmarking Methodology September 2026 Improper Block: The validation result in which packets with legitimate source addresses are blocked improperly due to inaccurate SAV rules or an inaccurate SAV table. The terms "improper block" and "false positive" are used synonymously in this document. Improper Permit: The validation result in which packets with spoofed source addresses are permitted improperly due to inaccurate SAV rules or an inaccurate SAV table. The terms "improper permit" and "false negative" are used synonymously in this document. Intra-domain SAV: SAV performed by an AS to validate the source addresses of data traffic that the AS originates directly or indirectly. Intra-domain SAV is applied at external interfaces on routers facing entities that are not deployed as neighboring ASes, such as a single host, a set of hosts, or a customer network with no AS. Inter-domain SAV: SAV performed by an AS on traffic received over an AS-to-AS interface that carries an eBGP session. Such interfaces include customer, provider, lateral peer, and RS/RS-client interfaces. Customer Network with No AS: A customer network that manages one or more IP prefixes but is not deployed as a neighboring AS of the SAV- performing AS. Neighboring AS: An AS directly connected to the SAV-performing AS using eBGP. The relationship can be Customer-to-Provider (C2P), Provider-to-Customer (P2C), lateral peering (P2P), or Route Server (RS) to RS-client. Customer Cone (CC): For a given AS, the set that includes the AS itself, its direct customer ASes, and all indirect customer ASes reachable recursively through provider-to-customer links. Prefixes in the Customer Cone: IP prefixes permitted by their owners to be originated by, or used as source addresses for data traffic originated from, one or more ASes within the customer cone. Limited Propagation of a Prefix (LPP): An inter-domain scenario in which a prefix is not propagated to all relevant ASes or interfaces due to mechanisms such as NO_EXPORT, NO_ADVERTISE, or selective export policies, while legitimate traffic using that prefix may still arrive at an interface where the prefix is not visible in BGP. Hidden Prefix (HP): A scenario in which an entity legitimately originates traffic using source addresses that are not visible to the routing or forwarding information used by the SAV mechanism. Chen, et al. Expires 18 March 2027 [Page 5] Internet-Draft SAV Benchmarking Methodology September 2026 Direct Server Return (DSR): A traffic delivery model commonly used by CDNs that use anycast service addresses while delivering data from edge locations that do not announce those addresses. A request is received by an anycast server or location, but the response is sent directly by another server using the anycast service address as the source address. This can create a legitimate hidden-prefix scenario. SAV-related Information: Routing information, such as RIBs and FIBs populated by routing protocols or local configuration information, and objects published in the Resource Public Key Infrastructure (RPKI) that were originally proposed for non-SAV purposes but may also be used for SAV. The RPKI objects include existing RPKI object types, such as ROAs and ASPAs, as well as any new types that may be proposed. SAV-specific Information: Information dedicated to SAV table generation. It may be defined and exchanged between ASes using a SAV-specific communication protocol or an extension of an existing protocol. The information may also take the form of SAV-specific RPKI object types or local configuration information provided by an operator. Configuration Information: Information configured locally by the network operator that describes the authorized use or propagation of source prefixes. Such information may be used by SAV mechanisms to generate or update SAV table. 3. Test Methodology 3.1. Test Setup The test setup in general is compliant with [RFC2544]. The DUT is connected to a Tester and other network devices to construct the network topology introduced in Section 5. The Tester is a traffic generator that generates network traffic with specified source and destination addresses in order to emulate spoofed or legitimate traffic. The Tester may also emulate routing peers, hosts, customer networks with no AS, or neighboring ASes, depending on the test case. Chen, et al. Expires 18 March 2027 [Page 6] Internet-Draft SAV Benchmarking Methodology September 2026 +~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Test Network Environment | | +--------------+ | | | | | +-->| | DUT | |---+ | | | | | | | | +--------------+ | | | +~~~~~~~~~~~~~~~~~~~~~~~~~~+ | | | | +--------------+ | +---------| Tester |<--------+ +--------------+ Figure 1: Generic Test Setup. Figure 1 illustrates the generic test configuration. Within the test network environment, the DUT can be interconnected with other devices to create the specific intra-domain or inter-domain test scenarios described in Section 5. The Tester may connect directly to the DUT or indirectly through other emulated routers or ASes. The Tester generates both spoofed and legitimate traffic for SAV accuracy tests and may generate traffic at controlled offered loads for data-plane performance tests. Accuracy tests MUST be conducted at an offered traffic rate below the loss-free forwarding capacity of the DUT. The DUT is expected to provide logs, counters, telemetry, or other observable outputs sufficient to compute the performance indicators defined in this document. 3.2. Network Topology and Device Configuration The position of the DUT within the test topology has an impact on SAV performance. Therefore, each benchmark report must identify the DUT location and the interface on which SAV is evaluated. For intra-domain SAV, the report must specify whether the DUT interface faces a single host, a set of hosts, or a customer network with no AS. For inter-domain SAV, the report must specify the business relationship between the SAV-performing AS and the neighboring AS on the tested interface. The relationship must be identified as customer, provider, lateral peer, RS, or RS-client when applicable. The routing, policy, and SAV configurations used in the test must be documented. Examples include IGP configuration, BGP configuration, business relationships, NO_EXPORT or NO_ADVERTISE communities, route- policy configuration, and any SAV-specific configuration. If the DUT uses SAV-related information or SAV-specific information, the sources and update procedures of that information should be documented. Chen, et al. Expires 18 March 2027 [Page 7] Internet-Draft SAV Benchmarking Methodology September 2026 When evaluating data-plane forwarding performance, the traffic generated by the Tester must be characterized by traffic rate, packet size distribution, ratio of spoofed to legitimate traffic, source prefix distribution, destination prefix distribution, and the ingress interface on which the traffic is received. 4. SAV Performance Indicators This section lists key performance indicators (KPIs) for SAV benchmarking tests. All KPIs should be measured in the applicable benchmarking scenarios described in Section 5. The standard deviation of repeated test results should be reported for each fixed test setup. The data-plane SAV table refresh rate and data-plane forwarding rate should be measured using varying SAV table sizes to show the sensitivity of the DUT to the SAV table size. 4.1. False Positive Rate The proportion of legitimate packets incorrectly classified as spoofed and blocked by the DUT to the total number of legitimate packets sent to the DUT. This metric corresponds to the improper block rate. For the purpose of this document, this metric is computed based on packet counts on a per-packet basis. Note that other computation methods, such as byte-count-based computation, may be used for supplementary analysis, but are outside the scope of the normative metric definition in this document. 4.2. False Negative Rate The proportion of spoofed packets incorrectly classified as legitimate and permitted by the DUT to the total number of spoofed packets sent to the DUT. This metric corresponds to the improper permit rate. For the purpose of this document, this metric is computed based on packet counts on a per-packet basis. Note that other computation methods, such as byte-count-based computation, may be used for supplementary analysis, but are outside the scope of the normative metric definition in this document. 4.3. Protocol Convergence Time The protocol convergence time represents the elapsed time from a relevant change in SAV-related information or SAV-specific information to the completion of the corresponding SAV table update on the DUT. Relevant changes can include route announcement, route withdrawal, policy change, prefix authorization change, configuration change, or SAV-specific information update. Where possible, the Chen, et al. Expires 18 March 2027 [Page 8] Internet-Draft SAV Benchmarking Methodology September 2026 report should distinguish the time consumed by underlying information convergence, SAV computation, and SAV table installation. 4.4. Protocol Message Processing Throughput The protocol message processing throughput measures the rate at which the DUT processes control-plane messages used to communicate SAV- related or SAV-specific information. It can indicate the SAV control-plane processing performance of the DUT. 4.5. Data Plane SAV Table Refreshing Rate The data-plane SAV table refreshing rate is the rate at which the DUT updates the data-plane SAV table. It reflects the ability of the DUT to install, update, or remove SAV entries in the data plane. 4.6. Data Plane Forwarding Rate The data-plane forwarding rate measures the throughput for processing data-plane traffic while SAV is enabled. The same forwarding-rate test should also be performed with SAV disabled, so that the relative performance impact of SAV can be reported. 4.7. Resource Utilization Resource utilization refers to the CPU, memory, and other relevant resources consumed by SAV control-plane and data-plane processes on the DUT. CPU and memory utilization should be recorded continuously during each test and should be reported separately for control-plane and data-plane components when possible. 5. Benchmarking Tests 5.1. Intra-domain SAV 5.1.1. False Positive and False Negative Rates *Objective*: Evaluate the false positive rate and false negative rate of the DUT when performing intra-domain SAV on external interfaces facing a single host, a set of hosts, or a customer network with no AS. The intra-domain SAV accuracy tests consist of three classic scenarios: asymmetric routing and hidden prefix. The baseline scenario exercises both improper-block and improper-permit behavior. The asymmetric-routing and hidden-prefix scenarios primarily expose improper blocks, while spoofed traffic can also be used to detect overly permissive validation behavior. The DUT should be evaluated Chen, et al. Expires 18 March 2027 [Page 9] Internet-Draft SAV Benchmarking Methodology September 2026 on the external interface where SAV is applied. The generated spoofed traffic should include different types of forged source addresses, such as source addresses not assigned to the connected entity, private-use or special-purpose addresses when applicable, internal-use-only prefixes of the AS, and external prefixes that are routable but not authorized for the tested ingress interface. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Test Network Environment | | +~~~~~~~~~~+ | | | Router 1 | | | FIB on DUT +~~~~~~~~~~+ | | Dest Next_hop /\ | | | 2001:db8::/55 Network 1 | | | | | \/ | | +----------+ | | | DUT | | | +----------+ | | /\ | | | Traffic with | | Traffic with | | source IP addresses | | destination IP addresses | | of 2001:db8::/55 | | of 2001:db8::/55 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | \/ +------------------------+ |Tester (Host or customer| | network with no AS) | | (2001:db8::/55) | +------------------------+ Figure 2: Intra-domain SAV facing host or customer network with no AS under symmetric routing scenario. *Intra-domain Symmetric Routing Scenario*: Figure 2 shows an intra- domain symmetric routing scenario. The Tester emulates a host, a set of hosts, or a customer network with no AS connected to the DUT. The Tester is authorized to originate traffic using 2001:db8::/55. The DUT applies intra-domain SAV on the interface facing the Tester. The *procedure* for this test is as follows: 1. Configure the DUT and other routers Figure 2 so that traffic from the Tester to destinations in the domain or outside the domain is forwarded through the DUT. 2. Configure or advertise the authorized source prefix 2001:db8::/55 according to the SAV mechanism under test. Chen, et al. Expires 18 March 2027 [Page 10] Internet-Draft SAV Benchmarking Methodology September 2026 3. Send legitimate traffic from the Tester using source addresses in 2001:db8::/55. 4. Send spoofed traffic from the Tester using source addresses not authorized for the Tester, for example 2001:db8:0:200::/55. 5. Vary the ratio of legitimate to spoofed traffic, for example from 1:9 to 9:1, and record the DUT counters or logs. 6. Measure the false positive rate and false negative rate. The test records whether the DUT properly permits the legitimate traffic and properly blocks the spoofed traffic. Any improper blocks and improper permits are reflected in the measured false positive and false negative rates. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Test Network Environment | | +~~~~~~~~~~+ | | | Router 2 | | | FIB on DUT +~~~~~~~~~~+ FIB on Router 1 | | Dest Next_hop /\ \ Dest Next_hop | | 2001:db8::/56 Network 1 / \ 2001:db8:0:100::/56 Network 1| | 2001:db8:0:100::/56 Router 2 / \/ 2001:db8::/56 Router 2 | | +----------+ +~~~~~~~~~~+ | | | DUT | | Router 1 | | | +----------+ +~~~~~~~~~~+ | | /\ / | | Traffic with \ / Traffic with | | source IP addresses \ / destination IP addresses | | of 2001:db8:0:100::/56 \ / of 2001:db8:0:100::/56 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ \ \/ +------------------------+ |Tester (Host or customer| | network with no AS) | | (2001:db8::/55) | +------------------------+ Figure 3: Intra-domain SAV facing host or customer network with no AS under asymmetric routing scenario. Chen, et al. Expires 18 March 2027 [Page 11] Internet-Draft SAV Benchmarking Methodology September 2026 *Intra-domain Asymmetric Routing Scenario*: Figure 3 shows an intra- domain asymmetric routing scenario. The host or customer network with no AS owns 2001:db8::/55 and is connected to both the DUT and Router 2. Inbound traffic for 2001:db8:0::/56 uses the DUT, while inbound traffic for 2001:db8:0:100::/56 uses Router 2. The customer network may nevertheless send outbound traffic with source addresses in 2001:db8:0:100::/56 through the DUT. This creates a legitimate asymmetric path. The *procedure* for this test is as follows: 1. Configure the topology shown in Figure 3. The Tester emulates the host or the customer network with no AS and connects to both the DUT and Router 2. 2. Configure the routing system so that the DUT's route to 2001:db8:0:100::/56 points away from the Tester, while the Tester can send traffic with source addresses in 2001:db8:0:100::/56 to the DUT. 3. Send legitimate traffic from the Tester to the DUT using source addresses in 2001:db8:0:100::/56. 4. Send spoofed traffic from the Tester to the DUT using source addresses not authorized for the Tester, for example 2001:db8:0:200::/55. 5. Vary the ratio of legitimate to spoofed traffic, for example from 1:9 to 9:1, and record the DUT counters or logs. 6. Measure the false positive rate and false negative rate. The test records whether the DUT permits the legitimate traffic that follows the asymmetric path and blocks the spoofed traffic. Any improper blocks and improper permits are reflected in the measured false positive and false negative rates. Chen, et al. Expires 18 March 2027 [Page 12] Internet-Draft SAV Benchmarking Methodology September 2026 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Test Network Environment | | +~~~~~~~~~~+ | | | Router 1 | | | FIB on DUT +~~~~~~~~~~+ | | Dest Next_hop /\ | | | 2001:db8::/55 Network 1 | | | | | \/ | | +----------+ | | | DUT | | | +----------+ | | /\ | | | Traffic with | | Traffic with | | source IP addresses | | destination IP addresses | | of 2001:db8::/55 | | of 2001:db8::/55 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | \/ +------------------------+ |Tester (Host or customer| | network with no AS) | +------------------------+ Visible/assigned prefix: 2001:db8::/56 Hidden source prefix: 2001:db8:0:100::/56 Figure 4: Intra-domain SAV under a hidden prefix scenario. *Intra-domain Hidden Prefix Scenario*: Figure 4 shows an intra-domain hidden prefix scenario. The Tester emulates a host or customer network with no AS that legitimately originates traffic from a source prefix not visible to the routing or forwarding information used by the SAV mechanism. Examples include DSR deployments or other cases where the authorized source prefix is not propagated within the operator's intra-domain routing system. The *procedure* for this test is as follows: 1. Configure the Tester as a host, a set of hosts, or a customer network with no AS connected to the DUT. 2. Configure the test so that 2001:db8::/56 is visible to the DUT as an assigned or routed prefix, while 2001:db8:0:100::/56 is a legitimate source prefix for the Tester but is not visible in the routing or forwarding information normally used by the DUT. 3. Send legitimate traffic from the Tester using source addresses in 2001:db8:0:100::/56. Chen, et al. Expires 18 March 2027 [Page 13] Internet-Draft SAV Benchmarking Methodology September 2026 4. Send spoofed traffic from the Tester using source addresses not authorized for the Tester. 5. Measure the false positive rate and false negative rate. The test records whether the DUT permits legitimate traffic from the hidden prefix and blocks spoofed control traffic. This scenario primarily exercises improper-block behavior. If the DUT does not support the information needed to authorize the hidden prefix, the report should record the resulting improper block behavior. 5.1.2. Control Plane Performance *Objective*: Measure the SAV protocol convergence performance of the DUT and, when applicable, the processing performance of control-plane messages used to communicate SAV-related or SAV-specific information. *Protocol Convergence Performance*: SAV protocol convergence is measured from a relevant input-state change until the corresponding SAV table has been updated on the DUT. The input-state change can be a route announcement or withdrawal, policy or configuration change, prefix-authorization change, or SAV-specific information update. The test should distinguish SAV convergence from the convergence of an underlying routing protocol when the distinction is observable. +~~~~~~~~~~~~~~~~~~~+ +-------------+ +-----------+ | Emulated Topology |------| Tester |<-------->| DUT | +~~~~~~~~~~~~~~~~~~~+ +-------------+ +-----------+ Figure 5: Test setup for control-plane performance measurement. The *procedure* for measuring protocol convergence is as follows: 1. Set up the test environment as depicted in Figure 5. 2. Establish a stable initial routing and SAV state and record the initial SAV table. 3. Trigger a specified number or percentage of changes in the information used by the DUT for SAV, for example by announcing or withdrawing prefixes, changing configuration or authorization information, or updating SAV-specific information. 4. Record the time at which the relevant change becomes observable to the DUT and the time at which the corresponding SAV table update is complete. Chen, et al. Expires 18 March 2027 [Page 14] Internet-Draft SAV Benchmarking Methodology September 2026 5. Repeat the test for different initial SAV table sizes and different numbers or percentages of changed entries. 6. Report SAV convergence time and, where observable, separately report the contribution of underlying routing or information convergence, SAV computation, and SAV table installation. For an IGP-driven test in which the trigger is an adjacency failure, the receipt time of the last hello message, or a more explicit shutdown indication when available, may be used as the routing-event timestamp as described in [RFC4061]. This timestamp represents the underlying routing trigger; the benchmark remains the time until the corresponding SAV table reaches the updated state. *Protocol Message Processing Performance*: This test is OPTIONAL and applies when the SAV mechanism receives explicit control-plane messages carrying information used for SAV. The offered load SHOULD be expressed primarily as messages per second, updates per second, or changed prefixes/objects per second rather than as a percentage of link capacity. Byte rate MAY be reported as a supplementary metric. The *procedure* for testing protocol message processing performance is as follows: 1. Set up the test environment as shown in Figure 5. 2. Send control-plane updates at increasing offered rates, expressed in messages per second and, where applicable, changed prefixes or SAV objects per second. 3. For each offered rate, record the number of messages or updates successfully processed, the processing interval, queueing or backlog when observable, and any message loss or processing failure. 4. Report the sustained processing throughput and the offered rate at which processing backlog or loss begins to occur. 5.1.3. Data Plane Performance *Objective*: Evaluate SAV table refresh performance and packet- processing performance while SAV is enabled. *Data Plane SAV Table Refreshing Performance*: This metric measures how quickly the DUT installs, modifies, or removes entries in the data-plane SAV table after the corresponding SAV state has been computed. Chen, et al. Expires 18 March 2027 [Page 15] Internet-Draft SAV Benchmarking Methodology September 2026 The *procedure* for testing data-plane SAV table refresh performance is as follows: 1. Establish an initial SAV table of a specified size. 2. Trigger a batch of changes that causes a specified number or percentage of SAV table entries to be added, modified, or removed. 3. Record the number of changed entries and the time from the start of data-plane installation until the update is complete. 4. Repeat the test for multiple initial SAV table sizes and multiple update sizes, for example 1%, 10%, 50%, and 100% of the table. 5. Report the refresh rate in entries per second and the total installation latency. Additions, modifications, and removals SHOULD be reported separately when their performance differs materially. *Data Plane Forwarding Performance*: The forwarding benchmark MUST distinguish intentional SAV filtering from unintended forwarding loss. The primary forwarding-performance comparison uses legitimate traffic and compares SAV enabled with SAV disabled. The Tester increases the offered load and determines the forwarding throughput at which legitimate traffic is forwarded without unintended loss according to the selected benchmarking procedure. A supplementary mixed-traffic test MAY combine legitimate and spoofed traffic to characterize SAV packet-processing behavior under different traffic compositions. For a mixed-traffic test, the report MUST separately identify the offered packet rate, legitimate forwarding rate, spoofed blocking rate, and any unintended loss. Intentionally blocked spoofed packets MUST NOT be counted as forwarding-performance loss. The *procedure* for testing data-plane forwarding performance is as follows: 1. Establish a stable, fully populated SAV table and record its size. 2. Send legitimate traffic at increasing offered loads and measure forwarding performance with SAV enabled. 3. Repeat the same traffic profile with SAV disabled and report the relative performance impact of SAV. Chen, et al. Expires 18 March 2027 [Page 16] Internet-Draft SAV Benchmarking Methodology September 2026 4. Optionally, repeat the test with mixtures of legitimate and spoofed traffic, varying the ratio, for example from 1:9 to 9:1. 5. For mixed traffic, report legitimate forwarding and spoofed blocking separately, together with any unintended packet loss. 5.2. Inter-domain SAV 5.2.1. False Positive and False Negative Rates *Objective*: Evaluate the false positive rate and false negative rate of the DUT when performing inter-domain SAV on an external interface connected to a neighboring AS. For the inter-domain SAV accuracy tests, at customer interfaces, these include Limited Propagation of a Prefix (LPP), Hidden Prefix (HP), and Source Address Spoofing within a Customer Cone (SCC). At provider interfaces, the primary improper-permit scenario is source address spoofing from providers. A symmetric-routing customer- interface test is retained as a baseline. The generated spoofed traffic should include source addresses belonging to prefixes outside the legitimate set for the tested ingress interface, prefixes originated elsewhere in the customer cone, prefixes originated by the SAV-performing AS, special-purpose or unallocated prefixes when applicable, and prefixes associated with other ASes. Chen, et al. Expires 18 March 2027 [Page 17] Internet-Draft SAV Benchmarking Methodology September 2026 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Test Network Environment | | +~~~~~~~~~~~~~~~~+ | | | AS 3(P3) | | | +~+/\~~~~~~+/\+~~+ | | / \ | | / \ | | / \ | | / (C2P) \ | | +------------------+ \ | | | DUT:AS 4(P4) | \ | | +-+/\+-+/\+----+/\++ \ | | / | \ \ | | P2[AS 2] / | \ \ | |P6[AS 2, AS 1] / | \ \ | |P1[AS 2, AS 1]/ (C2P) | \ P5[AS 5] \ P5[AS 5] | |+~~~~~~~~~~~~~~~~+ | \ \ | || AS 2(P2) | | P1[AS 1] \ \ | |+~~~~~~~~~~+/\+~~+ | P6[AS 1] \ \ | | \ | \ \ | | P6[AS 1] \ | \ \ | | P1[AS 1] \ | \ \ | | (C2P) \ | (C2P) (C2P) \ (C2P) \ | | +~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~+ | | | AS 1(P1, P6) | | AS 5(P5) | | | +~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~+ | | /\ | | | | | | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | \/ +----------------+ | Tester | +----------------+ Figure 6: SAV for customer-facing ASes in inter-domain symmetric routing scenario. *SAV at a Customer Interface under Symmetric Routing*: Figure 6 presents a test case for SAV in customer-facing ASes under an inter- domain symmetric routing scenario. In this setup, AS 1, AS 2, AS 3, the DUT, and AS 5 form the test network environment, with the DUT performing SAV at the AS level. AS 1 is a customer of both AS 2 and the DUT; AS 2 is a customer of the DUT, which in turn is a customer of AS 3; and AS 5 is a customer of both AS 3 and the DUT. AS 1 advertises prefixes P1 and P6 to AS 2 and the DUT, respectively. AS 2 then propagates routes for P1 and P6 to the DUT, enabling the DUT to learn these prefixes from both AS 1 and AS 2. In this test, the legitimate path for traffic with source addresses in P1 and Chen, et al. Expires 18 March 2027 [Page 18] Internet-Draft SAV Benchmarking Methodology September 2026 destination addresses in P4 is AS 1->AS 2->DUT. The Tester is connected to AS 1 to evaluate the DUT's SAV performance for customer- facing ASes. The *procedure* for testing SAV in this scenario is as follows: 1. To evaluate whether the DUT can generate accurate SAV rules for customer-facing ASes under symmetric inter-domain routing scenario, construct the test environment as shown in Figure 6. The Tester is connected to AS 1 and generates test traffic toward the DUT. 2. Configure AS 1, AS 2, AS 3, the DUT, and AS 5 to establish symmetric routing environment. 3. The Tester sends both legitimate traffic (with source addresses in P1 and destination addresses in P4) and spoofed traffic (with source addresses in P5 and destination addresses in P4) to the DUT via AS 2. The ratio of spoofed to legitimate traffic may vary, for example, from 1:9 to 9:1. The test records whether the DUT blocks the spoofed traffic and permits the legitimate traffic received from the direction of AS 2. Any improper block or improper permit is reflected in the measured false positive or false negative rate. Note that the DUT may also be placed at AS 1 or AS 2 in Figure 6 to evaluate its false positive and false negative rates using the same procedure. Chen, et al. Expires 18 March 2027 [Page 19] Internet-Draft SAV Benchmarking Methodology September 2026 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Test Network Environment | | +~~~~~~~~~~~~~~~~+ | | | AS 3(P3) | | | +~+/\~~~~~~+/\+~~+ | | / \ | | / \ | | / \ | | / (C2P) \ | | +------------------+ \ | | | DUT:AS 4(P4) | \ | | ++/\+--+/\+----+/\++ \ | | / | \ \ | | P2[AS 2] / | \ \ | |P6[AS 2, AS 1]/ | \ \ | | / (C2P) | \ P5[AS 5] \ P5[AS 5] | |+~~~~~~~~~~~~~~~~+ | \ \ | || AS 2(P2) | | P1[AS 1] \ \ | |+~~~~~~~~~~+/\+~~+ | P6[AS 1] \ \ | | P6[AS 1] \ | NO_EXPORT \ \ | | P1[AS 1] \ | \ \ | | NO_EXPORT \ | \ \ | | (C2P) \ | (C2P) (C2P) \ (C2P) \ | | +~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~+ | | | AS 1(P1, P6) | | AS 5(P5) | | | +~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~+ | | /\ | | | | | | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | \/ +----------------+ | Tester | +----------------+ Figure 7: SAV for customer-facing ASes in inter-domain asymmetric routing scenario caused by NO_EXPORT. *SAV at a Customer Interface under the Limited Propagation of a Prefix (LPP) Scenario*: Figure 7 presents a test case for SAV at a customer interface under a Limited Propagation of a Prefix (LPP) scenario. In this example, limited propagation is induced by NO_EXPORT community configuration. In this setup, AS 1, AS 2, AS 3, the DUT, and AS 5 form the test network, with the DUT performing SAV at the AS level. AS 1 is a customer of both AS 2 and the DUT; AS 2 is a customer of the DUT, which is itself a customer of AS 3; and AS 5 is a customer of both AS 3 and the DUT. AS 1 advertises prefix P1 to AS 2 with the NO_EXPORT community attribute, preventing AS 2 from propagating the route for P1 to the DUT. Similarly, AS 1 advertises Chen, et al. Expires 18 March 2027 [Page 20] Internet-Draft SAV Benchmarking Methodology September 2026 prefix P6 to the DUT with the NO_EXPORT attribute, preventing the DUT from propagating this route to AS 3. As a result, the DUT learns the route for prefix P1 only from AS 1. The legitimate path for traffic with source addresses in P1 and destination addresses in P4 is AS 1->AS 2->DUT. The Tester is connected to AS 1 to evaluate the DUT's SAV performance for customer-facing ASes. The *procedure* for testing SAV in this asymmetric routing scenario is as follows: 1. To evaluate the DUT under an LPP scenario created using NO_EXPORT, construct the test environment as shown in Figure 7. The Tester is connected to AS 1 and generates test traffic toward the DUT. 2. Configure AS 1, AS 2, AS 3, the DUT, and AS 5 to establish the asymmetric routing scenario. 3. The Tester sends both legitimate traffic (with source addresses in P1 and destination addresses in P4) and spoofed traffic (with source addresses in P5 and destination addresses in P4) to the DUT via AS 2. The ratio of spoofed to legitimate traffic may vary—for example, from 1:9 to 9:1. The test records whether the DUT blocks the spoofed traffic and permits the legitimate traffic received from the direction of AS 2. Any improper block or improper permit is reflected in the measured false positive or false negative rate. Note that the DUT may also be placed at AS 1 or AS 2 in Figure 7 to evaluate its false positive and false negative rates using the same procedure. Chen, et al. Expires 18 March 2027 [Page 21] Internet-Draft SAV Benchmarking Methodology September 2026 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Test Network Environment | | +----------------+ | | Anycast Server+-+ AS 3(P3, P7) | | | +-+/\----+/\+----+ | | / \ | | / P3[AS 3] / \ P3[AS 3] \ | | / P7[AS 3] / \ P7[AS 3] \ | | \/ / (C2P) \ \/ | | +----------------+ \ | | | DUT: AS 4(P4) | \ | | ++/\+--+/\+--+/\++ \ | | / | \ \ | | / P3[AS 4, AS 3] / | \ \ | | / P7[AS 4, AS 3] / | \ \ | | \/ / (C2P) | \ P5[AS 5] \ P5[AS 5] | | +----------------+ | \ \ | |User+-+ AS 2(P2) | | P1[AS 1] \ \ | | +----------+/\+--+ | P6[AS 1] \ \ | | \ | \ \ | | P6[AS 1] \ | \ \ | | P1[AS 1] \ | \ \ | | \(C2P) |(C2P) (C2P)\ (C2P)\ | | +---------------+ +----------------+ | | Edge Server+-+ AS 1(P1, P6) | | AS 5(P5) | | | +----------------+ +----------------+ | | /\ | | | | | | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | \/ +----------------+ | Tester | | (Edge Server) | +----------------+ P7 is the anycast prefix and is originated only by AS 3 via BGP. Note that the prefix route propagations relevant to the DSR scenario are depicted; not all prefix propagations are depicted. Figure 8: SAV for customer-facing ASes in the scenario of hidden prefix caused by direct server return (DSR). *SAV at a Customer Interface under the Hidden Prefix (HP) Scenario*: Figure 8 presents a test case for SAV at a customer interface under a Hidden Prefix (HP) scenario. DSR is used as one representative realization of the HP scenario. In this setup, AS 1, AS 2, AS 3, the DUT, and AS 5 form the test network, with the DUT performing SAV at the AS level. AS 1 is a customer of both AS 2 and the DUT; AS 2 is a customer of the DUT, which is itself a customer of AS 3; and AS 5 is Chen, et al. Expires 18 March 2027 [Page 22] Internet-Draft SAV Benchmarking Methodology September 2026 a customer of both AS 3 and the DUT. When users in AS 2 send requests to an anycast destination IP in P7, the forwarding path is AS 2->DUT->AS 3. Anycast servers in AS 3 receive the requests and tunnel them to edge servers in AS 1. The edge servers then return content to the users with source addresses in prefix P7. If the reverse forwarding path is AS 1->DUT->AS 2, the Tester sends traffic with source addresses in P7 and destination addresses in P2 along the path AS 1->DUT->AS 2. Alternatively, if the reverse forwarding path is AS 1->AS 2, the Tester sends traffic with source addresses in P7 and destination addresses in P2 along the path AS 1->AS 2. In this case, AS 2 may serve as the DUT. The *procedure* for testing SAV in this DSR scenario is as follows: 1. To evaluate whether the DUT can generate accurate SAV rules under DSR conditions, construct the test environment as shown in Figure 8. The Tester is connected to AS 1 and generates test traffic toward the DUT. 2. Configure AS 1, AS 2, AS 3, the DUT, and AS 5 to establish the DSR scenario. 3. The Tester sends legitimate traffic (with source addresses in P7 and destination addresses in P2) to AS 2 via the DUT. The test records whether the DUT permits legitimate traffic with source addresses in P7 received from the direction of AS 1. This HP scenario primarily exercises improper-block behavior. Other HP cases, including prefixes legitimately used only as source addresses without being advertised through BGP, may be tested using the same methodology. Note that the DUT may also be placed at AS 1 or AS 2 in Figure 8 to evaluate its false positive and false negative rates using the same procedure. Chen, et al. Expires 18 March 2027 [Page 23] Internet-Draft SAV Benchmarking Methodology September 2026 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Test Network Environment | | +----------------+ | | | AS 3(P3) | | | +--+/\+--+/\+----+ | | / \ | | / \ | | / \ | | / (C2P) \ | | +----------------+ \ | | | DUT(P4) | \ | | ++/\+--+/\+--+/\++ \ | | P6[AS 1, AS 2] / | \ \ | | P2[AS 2] / | \ \ | | / | \ \ | | / (C2P) | \ P5[AS 5] \ P5[AS 5] | +----------+ | +----------------+ | \ \ | | Tester |-|->| | | \ \ | |(Attacker)| | | AS 2(P2) | | \ \ | | (P1') |<|--| | | P1[AS 1] \ \ | +----------+ | +---------+/\+---+ | P6[AS 1] \ \ | | P6[AS 1] \ | NO_EXPORT \ \ | | P1[AS 1] \ | \ \ | | NO_EXPORT \ | \ \ | | \ (C2P) | (C2P) (C2P) \ (C2P) \ | | +----------------+ +----------------+ | | Victim+-+ AS 1(P1, P6) | Server+-+ AS 5(P5) | | | +----------------+ +----------------+ | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ P1' is the spoofed source prefix P1 by the attacker which is inside of AS 2 or connected to AS 2 through other ASes. Figure 9: SAV for customer-facing ASes in the scenario of reflection attacks. *SAV at a Customer Interface under the Source Address Spoofing within a Customer Cone (SCC) Scenario -- Reflection Variant*: Figure 9 illustrates a test case for SAV in customer-facing ASes under a reflection attack scenario. In this SCC scenario, source address spoofing occurs within the DUT's customer cone and is used to trigger a reflection attack. The attacker spoofs the victim's IP address (P1) and sends requests to server IP addresses (P5) that are configured to respond to such requests. The Tester emulates the attacker by performing source address spoofing. The arrows in Figure 9 indicate the business relationships between ASes: AS 3 serves as the provider for both the DUT and AS 5, while the DUT acts as the provider for AS 1, AS 2, and AS 5. Additionally, AS 2 is the provider for AS 1. Chen, et al. Expires 18 March 2027 [Page 24] Internet-Draft SAV Benchmarking Methodology September 2026 The *procedure* for testing SAV under reflection attack conditions is as follows: 1. To evaluate whether the DUT can generate accurate SAV rules in a reflection attack scenario, construct the test environment as shown in Figure 9. The Tester is connected to AS 2 and generates test traffic toward the DUT. 2. Configure AS 1, AS 2, AS 3, the DUT, and AS 5 to simulate the reflection attack scenario. 3. The Tester sends spoofed traffic (with source addresses in P1 and destination addresses in P5) toward AS 5 via the DUT. The test records whether the DUT blocks spoofed traffic with source addresses in P1 received from the direction of AS 2. This SCC variant primarily exercises improper-permit behavior. Note that the DUT may also be placed at AS 1 or AS 2 in Figure 9 to evaluate its false positive and false negative rates using the same procedure. Chen, et al. Expires 18 March 2027 [Page 25] Internet-Draft SAV Benchmarking Methodology September 2026 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Test Network Environment | | +----------------+ | | | AS 3(P3) | | | +--+/\+--+/\+----+ | | / \ | | / \ | | / \ | | / (C2P) \ | | +----------------+ \ | | | DUT(P4) | \ | | ++/\+--+/\+--+/\++ \ | | P6[AS 1, AS 2] / | \ \ | | P2[AS 2] / | \ \ | | / | \ \ | | / (C2P) | \ P5[AS 5] \ P5[AS 5] | +----------+ | +----------------+ | \ \ | | Tester |-|->| | | \ \ | |(Attacker)| | | AS 2(P2) | | \ \ | | (P5') |<|--| | | P1[AS 1] \ \ | +----------+ | +---------+/\+---+ | P6[AS 1] \ \ | | P6[AS 1] \ | NO_EXPORT \ \ | | P1[AS 1] \ | \ \ | | NO_EXPORT \ | \ \ | | \ (C2P) | (C2P) (C2P) \ (C2P) \ | | +----------------+ +----------------+ | | Victim+-+ AS 1(P1, P6) | | AS 5(P5) | | | +----------------+ +----------------+ | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ P5' is the spoofed source prefix P5 by the attacker which is inside of AS 2 or connected to AS 2 through other ASes. Figure 10: SAV for customer-facing ASes in the scenario of direct attacks. *SAV at a Customer Interface under the Source Address Spoofing within a Customer Cone (SCC) Scenario -- Direct Variant*: Figure 10 presents a test case for SAV in customer-facing ASes under a direct attack scenario. In this SCC scenario, source address spoofing occurs within the DUT's customer cone and the spoofed traffic is sent directly toward the victim. The attacker spoofs a source address (P5) and directly targets the victim's IP address (P1), aiming to overwhelm its network resources. The Tester emulates the attacker by performing source address spoofing. The arrows in Figure 10 indicate the business relationships between ASes: AS 3 serves as the provider for both the DUT and AS 5, while the DUT acts as the provider for AS 1, AS 2, and AS 5. Additionally, AS 2 is the provider for AS 1. Chen, et al. Expires 18 March 2027 [Page 26] Internet-Draft SAV Benchmarking Methodology September 2026 The *procedure* for testing SAV under direct attack conditions is as follows: 1. To evaluate whether the DUT can generate accurate SAV rules in a direct attack scenario, construct the test environment as shown in Figure 10. The Tester is connected to AS 2 and generates test traffic toward the DUT. 2. Configure AS 1, AS 2, AS 3, the DUT, and AS 5 to simulate the direct attack scenario. 3. The Tester sends spoofed traffic (with source addresses in P5 and destination addresses in P1) toward AS 1 via the DUT. The test records whether the DUT blocks spoofed traffic with source addresses in P5 received from the direction of AS 2. This SCC variant primarily exercises improper-permit behavior. Note that DUT may also be placed at AS 1 or AS 2 in Figure 10 to evaluate its false positive and false negative rates using the same procedure. Chen, et al. Expires 18 March 2027 [Page 27] Internet-Draft SAV Benchmarking Methodology September 2026 +----------------+ | Tester | | (Attacker) | | (P1') | +----------------+ | /\ | | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Test Network Environment \/ | | | +----------------+ | | | | | | | AS 3(P3) | | | | | | | +-+/\----+/\+----+ | | / \ | | / \ | | / \ | | / (C2P/P2P) \ | | +----------------+ \ | | | DUT(P4) | \ | | ++/\+--+/\+--+/\++ \ | | P6[AS 1, AS 2] / | \ \ | | P2[AS 2] / | \ \ | | / | \ \ | | / (C2P) | \ P5[AS 5] \ P5[AS 5] | | +----------------+ | \ \ | |Server+-+ AS 2(P2) | | P1[AS 1] \ \ | | +----------+/\+--+ | P6[AS 1] \ \ | | P6[AS 1] \ | NO_EXPORT \ \ | | P1[AS 1] \ | \ \ | | NO_EXPORT \ | \ \ | | \ (C2P) | (C2P) (C2P) \ (C2P) \ | | +----------------+ +----------------+ | | Victim+-+ AS 1(P1, P6) | | AS 5(P5) | | | +----------------+ +----------------+ | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ P1' is the spoofed source prefix P1 by the attacker which is inside of AS 3 or connected to AS 3 through other ASes. Figure 11: SAV for provider-facing ASes in the scenario of reflection attacks. *SAV at a Provider Interface under the Spoofing-from-Providers Scenario -- Reflection Variant*: Figure 11 illustrates a test case for SAV in provider/peer-facing ASes under a reflection attack scenario. In this scenario, the attacker spoofs the victim's IP address (P1) and sends requests to server IP addresses (P2) that are configured to respond. The Tester emulates the attacker by Chen, et al. Expires 18 March 2027 [Page 28] Internet-Draft SAV Benchmarking Methodology September 2026 performing source address spoofing. The servers then send overwhelming responses to the victim, exhausting its network resources. The arrows in Figure 11 represent the business relationships between ASes: AS 3 acts as either a provider or a lateral peer of the DUT and is the provider for AS 5, while the DUT serves as the provider for AS 1, AS 2, and AS 5. Additionally, AS 2 is the provider for AS 1. The *procedure* for testing SAV under reflection attack conditions is as follows: 1. To evaluate the DUT under a spoofing-from-providers scenario using reflection traffic, construct the test environment as shown in Figure 11. The Tester is connected to AS 3 and generates test traffic toward the DUT. 2. Configure AS 1, AS 2, AS 3, the DUT, and AS 5 to simulate the reflection attack scenario. 3. The Tester sends spoofed traffic (with source addresses in P1 and destination addresses in P2) toward AS 2 via AS 3 and the DUT. The test records whether the DUT blocks spoofed traffic with source addresses in P1 received from the direction of AS 3. This spoofing- from-providers variant primarily exercises improper-permit behavior. Note that the DUT may also be placed at AS 1 or AS 2 in Figure 11 to evaluate its false positive and false negative rates using the same procedure. Chen, et al. Expires 18 March 2027 [Page 29] Internet-Draft SAV Benchmarking Methodology September 2026 +----------------+ | Tester | | (Attacker) | | (P2') | +----------------+ | /\ | | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Test Network Environment \/ | | | +----------------+ | | | AS 3(P3) | | | +-+/\----+/\+----+ | | / \ | | / \ | | / \ | | / (C2P/P2P) \ | | +----------------+ \ | | | DUT(P4) | \ | | ++/\+--+/\+--+/\++ \ | | P6[AS 1, AS 2] / | \ \ | | P2[AS 2] / | \ \ | | / | \ \ | | / (C2P) | \ P5[AS 5] \ P5[AS 5] | |+----------------+ | \ \ | || AS 2(P2) | | P1[AS 1] \ \ | |+----------+/\+--+ | P6[AS 1] \ \ | | P6[AS 1] \ | NO_EXPORT \ \ | | P1[AS 1] \ | \ \ | | NO_EXPORT \ | \ \ | | \ (C2P) | (C2P) (C2P) \ (C2P) \ | | +----------------+ +----------------+ | | Victim+-+ AS 1(P1, P6) | | AS 5(P5) | | | +----------------+ +----------------+ | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ P2' is the spoofed source prefix P2 by the attacker which is inside of AS 3 or connected to AS 3 through other ASes. Figure 12: SAV for provider-facing ASes in the scenario of direct attacks. Chen, et al. Expires 18 March 2027 [Page 30] Internet-Draft SAV Benchmarking Methodology September 2026 *SAV at a Provider Interface under the Spoofing-from-Providers Scenario -- Direct Variant*: Figure 12 presents a test case for SAV in provider-facing ASes under a direct attack scenario. In this scenario, the attacker spoofs a source address (P2) and directly targets the victim's IP address (P1), overwhelming its network resources. The arrows in Figure 12 represent the business relationships between ASes: AS 3 acts as either a provider or a lateral peer of the DUT and is the provider for AS 5, while the DUT serves as the provider for AS 1, AS 2, and AS 5. Additionally, AS 2 is the provider for AS 1. The procedure for testing SAV under direct attack conditions is as follows: 1. To evaluate the DUT under a spoofing-from-providers scenario using direct traffic, construct the test environment as shown in Figure 12. The Tester is connected to AS 3 and generates test traffic toward the DUT. 2. Configure AS 1, AS 2, AS 3, the DUT, and AS 5 to simulate the direct attack scenario. 3. The Tester sends spoofed traffic (with source addresses in P2 and destination addresses in P1) toward AS 1 via AS 3 and the DUT. The test records whether the DUT blocks spoofed traffic with source addresses in P2 received from the direction of AS 3. This spoofing- from-providers variant primarily exercises improper-permit behavior. Note that the DUT may also be placed at AS 1 or AS 2 in Figure 12 to evaluate its false positive and false negative rates using the same procedure. *Applicability to Peer and Route-Server Interfaces*: For a lateral peer interface, the applicable accuracy test depends on the validation model used by the DUT. If the interface is validated using customer-interface-like directionality, the customer-interface test cases apply. If it is validated using provider-interface-like relaxed filtering, the provider-interface test cases apply. For an RS-to-RS-client interface, the customer-interface tests can be applied. For an RS-client-to-RS interface, the provider-interface tests may be applied as a simplified model, or the interface may be treated as the union of the lateral peers selected by the RS client. *Additional Operational Dynamics*: The following FRR and routing- policy-change tests are supplementary operational scenarios. They evaluate whether SAV behavior remains stable while routing or forwarding state changes. Chen, et al. Expires 18 March 2027 [Page 31] Internet-Draft SAV Benchmarking Methodology September 2026 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Test Network Environment | | +-----------+ +-----------+ | | | AS3 |------------| AS2 | | | +-----------+ +-----------+ | | /\ /\ | | | | | | primary link | backup link | | | | (C2P) | (C2P) | | +-----------------------------------------+ | | | DUT | | | +-----------------------------------------+ | | /\ | | | | | | Legitimate and | | | Spoofed Traffic | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | (C2P) +-------------+ | Tester | +-------------+ Figure 13: Inter-domain SAV under FRR scenario. *SAV for Customer-facing ASes under FRR Scenario*: Inter-domain Fast Reroute (FRR) mechanisms, such as BGP Prefix Independent Convergence (PIC) or MPLS-based FRR, allow rapid failover between ASes after a link or node failure. These events may temporarily desynchronize routing information and SAV rules. The *procedure* for testing SAV under FRR scenario is as follows: 1. Configure FRR or BGP PIC on the DUT for inter-AS links to AS3 (primary) and AS2 (backup). 2. Continuously send legitimate and spoofed traffic from AS1 toward DUT. 3. Trigger a failure on the AS3–DUT link to activate the FRR path via AS2. 4. Measure false positive and false negative rates during and after switchover. 5. Restore the AS3 link and verify SAV table consistency. Chen, et al. Expires 18 March 2027 [Page 32] Internet-Draft SAV Benchmarking Methodology September 2026 The test records false positive and false negative rates during and after the FRR switchover, together with protocol convergence time. Any transient improper permits or improper blocks are reported rather than treated as a pass/fail criterion. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Test Network Environment | | +-----------+ +-----------+ | | | AS3 |------------| AS2 | | | +-----------+ +-----------+ | | /\ /\ | | | | | | | preferred path | default path| | | (C2P) | (C2P) | | +-----------------------------------------+ | | | DUT | | | +-----------------------------------------+ | | /\ | | | Legitimate and | | | Spoofed Traffic | | | | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | (C2P) +-------------+ | Tester | +-------------+ Figure 14: Inter-domain SAV under PBR scenario. *SAV for Customer-facing ASes under PBR Scenario*: In inter-domain environments, routing policies such as local preference, route maps, or communities may alter path selection independently of shortest- path routing. Such policy-driven forwarding can affect how the SAV rules are derived and applied. The *procedure* for testing SAV under PBR scenario is as follows: 1. Configure a routing policy on the DUT (e.g., set local preference) to prefer AS3 for specific prefixes while maintaining AS2 as an alternative path. 2. Generate legitimate and spoofed traffic from AS1 matching both policy-affected and unaffected prefixes. 3. Observe SAV filtering behavior before and after policy changes. 4. Modify the routing policy dynamically and measure false positive and false negative rates. Chen, et al. Expires 18 March 2027 [Page 33] Internet-Draft SAV Benchmarking Methodology September 2026 The test records false positive and false negative rates before, during, and after the routing-policy change, together with protocol convergence time. Any transient improper permits or improper blocks are reported. 5.2.2. Control Plane Performance The test setup, procedure, and metrics for evaluating protocol convergence and protocol message processing performance can refer to Section 5.1.2. SAV convergence testing applies to dynamic SAV mechanisms whenever a relevant input-state change can cause the SAV table to be recomputed or updated. SAV protocol message processing throughput is OPTIONAL and applies when the mechanism receives explicit control-plane messages carrying SAV-related or SAV-specific information. 5.2.3. Data Plane Performance The test setup, procedure, and metrics for evaluating data-plane SAV table refresh performance and data-plane forwarding performance can refer to Section 5.1.3. 5.3. Resource Utilization When evaluating the DUT for both intra-domain (Section 5.1) and inter-domain SAV (Section 5.2) functionality, CPU utilization (for both control and data planes) and memory utilization (for both control and data planes) SHOULD be recorded. These metrics should be recorded continuously and be collected separately per plane to facilitate granular performance analysis. 6. Reporting Format Each test report must include both global parameters and test- specific parameters. The following parameters for test configuration and SAV mechanism settings must be documented in the test report. Test configuration parameters consist of: 1. Test device hardware and software versions. 2. DUT deployment type, such as hardware router, software router, VM, or container. 3. Network topology, including the location of the DUT and the interface on which SAV is evaluated. Chen, et al. Expires 18 March 2027 [Page 34] Internet-Draft SAV Benchmarking Methodology September 2026 4. Intra-domain interface type, if applicable: single host, set of hosts, or customer network with no AS. 5. Inter-domain relationship type, if applicable: customer, provider, lateral peer, RS, or RS-client. 6. Routing configuration, including IGP, BGP, route-policy, NO_EXPORT/NO_ADVERTISE, selective export, and any other policy configuration relevant to the test. 7. SAV mechanism and configuration, including whether the DUT uses SAV-related information, SAV-specific information, or a combination of both. 8. SAV table size and update characteristics. 9. Test traffic attributes, including packet size, traffic rate, source prefix distribution, destination prefix distribution, and the ratio of spoofed to legitimate traffic. 10. System configuration, including CPU, memory, caches, operating system, interface capacity, and hardware offload features when applicable. 11. Measurement method, including DUT logs, counters, telemetry, Tester observations, and timestamp sources. 12. Number of repeated runs and statistical treatment of the results. For each accuracy test, the report must identify which packets are legitimate and which packets are spoofed, and why. For each SAV convergence test, the report must identify the triggering event, the timestamping method, and, where observable, the distinction between underlying information convergence and SAV-table computation or installation. For each performance test, the report must identify whether SAV was enabled or disabled and whether the DUT was operating in steady state or during SAV table update. 7. IANA Considerations This document has no IANA actions. 8. Security Considerations The benchmarking tests outlined in this document are confined to evaluating the performance of SAV devices within a controlled laboratory environment using isolated networks. Chen, et al. Expires 18 March 2027 [Page 35] Internet-Draft SAV Benchmarking Methodology September 2026 The network topology employed for benchmarking MUST constitute an independent test setup. It MUST remain disconnected from devices that could relay test traffic into an operational production network. Spoofed traffic generated for the benchmarking tests MUST NOT be leaked outside the controlled test environment. 9. Normative References [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, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [RFC4061] Manral, V., White, R., and A. Shaikh, "Benchmarking Basic OSPF Single Router Control Plane Convergence", RFC 4061, DOI 10.17487/RFC4061, April 2005, . [RFC5210] Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams, "A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience", RFC 5210, DOI 10.17487/RFC5210, June 2008, . [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, . [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, . [I-D.ietf-savnet-intra-domain-problem-statement] Qin, L., Li, D., Wu, J., Huang, M., and N. Geng, "Problem Statement, Gap Analysis, and Requirements for Intra-domain Source Address Validation", Work in Progress, Internet- Draft, draft-ietf-savnet-intra-domain-problem-statement- 26, 1 June 2026, . Chen, et al. Expires 18 March 2027 [Page 36] Internet-Draft SAV Benchmarking Methodology September 2026 [I-D.ietf-savnet-inter-domain-problem-statement] Li, D., Qin, L., Liu, L., Huang, M., and K. Sriram, "Problem Statement, Gap Analysis, and Requirements for Inter-Domain Source Address Validation", Work in Progress, Internet-Draft, draft-ietf-savnet-inter-domain-problem- statement-21, 19 July 2026, . [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, . Acknowledgements Many thanks to Aijun Wang, Nan Geng, Susan Hares, Giuseppe Fioccola, Minh-Ngoc Tran, Shengnan Yue, Changwang Lin, Yuanyuan Zhang, Xueyan Song, Yangfei Guo, Shenglin Jiang, Tian Tong, Meng Li, Ron Bonica, and Mohamed Boucadair for their valuable comments and reviews on this document. Apologies to any others whose names the authors may have missed mentioning. Appendix A. Summary of Changes (to be removed by RFC Editor before publication) A.1. Changes from Version -03 to Version -04 The major changes from version -03 to version -04 are as follows: * Aligned the terminology and scope more closely with the latest intra-domain and inter-domain SAV problem statements, including Proper Block, Proper Permit, SAV Table, SAV-related Information, SAV-specific Information, and Configuration Information. * Reorganized the accuracy-test descriptions around the SAVNET gap scenarios: asymmetric routing and hidden prefix for intra-domain SAV, and LPP, HP, SCC, and spoofing from providers for inter- domain SAV. Clarified the applicability of the tests to peer and RS/RS-client interfaces. Chen, et al. Expires 18 March 2027 [Page 37] Internet-Draft SAV Benchmarking Methodology September 2026 * Clarified that accuracy benchmarking records improper blocks and improper permits rather than defining pass/fail conformance requirements, and required SAV-induced drops to be distinguishable from unrelated packet loss. * Refined SAV protocol convergence and control-plane performance measurements by using message/update rates and changed-prefix or object rates rather than percentages of link capacity. * Refined SAV-table refresh benchmarking to vary initial table size and the number or percentage of changed entries, and report refresh rate and installation latency. * Refined data-plane forwarding benchmarking so that intentional blocking of spoofed packets is not counted as forwarding loss, and separated legitimate forwarding performance from supplementary mixed legitimate/spoofed traffic tests. * Classified FRR and routing-policy-change tests as additional operational-dynamics scenarios, and corrected editorial and consistency issues in the figures, terminology, and references. A.2. Changes from Version -02 to Version -03 The major change from version -02 to version -03 is as follows: * Added an appendix summarizing the major changes introduced across document revisions to improve revision traceability. No technical changes to the benchmarking methodology or benchmark procedures were introduced in version -03. A.3. Changes from Version -01 to Version -02 The major changes from version -01 to version -02 are as follows: * Clarified the scope of the document as a black-box laboratory benchmarking methodology for individual SAV devices and refined the generic test methodology. * Expanded and refined the SAV terminology and deployment scope to align with the intra-domain and inter-domain SAV problem statements. * Restructured the intra-domain SAV accuracy tests into symmetric routing, asymmetric routing, and hidden-prefix scenarios, and added an explicit hidden-prefix benchmarking scenario. Chen, et al. Expires 18 March 2027 [Page 38] Internet-Draft SAV Benchmarking Methodology September 2026 * Refined the inter-domain SAV accuracy tests according to the relationship of the tested interface with the neighboring AS, and clarified the limited prefix propagation and DSR scenarios. * Refined the SAV performance indicators and clarified the generation and classification of legitimate and spoofed test traffic. * Expanded the reporting requirements and strengthened the security considerations for isolated benchmarking environments. A.4. Changes from Version -00 to Version -01 The major changes from version -00 to version -01 are as follows: * Clarified the computation method of false positive rate and false negative rate. * Updated the example IP prefixes in the intra-domain test scenarios to use IPv6 documentation prefixes. * Revised the DSR test scenario by introducing a dedicated anycast prefix and clarifying the corresponding route propagation and legitimate traffic paths. * Clarified the collection of resource utilization metrics, including continuous measurement and separate control-plane and data-plane measurements where possible. Authors' Addresses Li Chen Zhongguancun Laboratory Beijing China Email: lichen@zgclab.edu.cn Dan Li Tsinghua University Beijing China Email: tolidan@tsinghua.edu.cn Chen, et al. Expires 18 March 2027 [Page 39] Internet-Draft SAV Benchmarking Methodology September 2026 Libin Liu Zhongguancun Laboratory Beijing China Email: liulb@zgclab.edu.cn Lancheng Qin Zhongguancun Laboratory Beijing China Email: qinlc@zgclab.edu.cn Chen, et al. Expires 18 March 2027 [Page 40]