Benchmarking Methodology for Intra-domain and Inter-domain Source Address Validation

Benchmarking Tests

Intra-domain SAV

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 test cases in this section evaluate the symmetric routing scenario, the asymmetric routing scenario, the hidden prefix scenario, and spoofed traffic that may expose overly permissive validation behavior. The DUT should be evaluated 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.

Intra-domain SAV facing host or customer network with no AS under symmetric routing scenario. Intra-domain Symmetric Routing Scenario: 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:

Configure the DUT and other routers so that traffic from the Tester to destinations in the domain or outside the domain is forwarded through the DUT.
Configure or advertise the authorized source prefix 2001:db8::/55 according to the SAV mechanism under test.
Send legitimate traffic from the Tester using source addresses in 2001:db8::/55.
Send spoofed traffic from the Tester using source addresses not authorized for the Tester, for example 2001:db8:0:200::/55.
Vary the ratio of legitimate to spoofed traffic, for example from 1:9 to 9:1, and record the DUT counters or logs.
Measure the false positive rate and false negative rate.

The expected result is that the DUT properly permits legitimate traffic and properly blocks spoofed traffic.

Intra-domain SAV facing host or customer network with no AS under asymmetric routing scenario. Intra-domain Asymmetric Routing Scenario: 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:

Configure the topology shown in . The Tester emulates the host or the customer network with no AS and connects to both the DUT and Router 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.
Send legitimate traffic from the Tester to the DUT using source addresses in 2001:db8:0:100::/56.
Send spoofed traffic from the Tester to the DUT using source addresses not authorized for the Tester, for example 2001:db8:0:200::/55.
Vary the ratio of legitimate to spoofed traffic, for example from 1:9 to 9:1, and record the DUT counters or logs.
Measure the false positive rate and false negative rate.

The expected result is that the DUT properly permits legitimate traffic that follows an asymmetric path and properly blocks spoofed traffic.

Intra-domain SAV under a hidden prefix scenario. Intra-domain Hidden Prefix Scenario: 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:

Configure the Tester as a host, a set of hosts, or a customer network with no AS connected to the DUT.
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.
Send legitimate traffic from the Tester using source addresses in 2001:db8:0:100::/56.
Send spoofed traffic from the Tester using source addresses not authorized for the Tester.
Measure the false positive rate and false negative rate.

The expected result is that a SAV mechanism capable of handling hidden prefixes properly permits legitimate traffic from the hidden prefix and properly blocks spoofed traffic. If the DUT does not support the information needed to authorize the hidden prefix, the report should record the resulting improper block behavior.

Control Plane Performance Objective: Measure the control plane performance of the DUT, including both protocol convergence performance and protocol message processing performance in response to route changes caused by network failures or operator configurations. Protocol convergence performance is quantified by the convergence time, defined as the duration from the onset of a routing change until the completion of the corresponding SAV rule update. Protocol message processing performance is measured by the processing throughput, represented by the total size of protocol messages processed per second. Note that the tests for control plane performance of the DUT which performs intra-domain SAV are OPTIONAL. Only DUT which implements the SAV mechanism using an explicit control-plane communication protocol, such as SAV-specific information communication mechanism proposed in should be tested on its control plane performance.

Test setup for protocol convergence performance measurement. | DUT | +~~~~~~~~~~~~~~~~~~~+ +-------------+ +-----------+ ]]> Protocol Convergence Performance: illustrates the test setup for measuring protocol convergence performance. The convergence process of the DUT, during which SAV rules are updated, is triggered by route changes resulting from network failures or operator configurations. In , the Tester is directly connected to the DUT and simulates these route changes by adding or withdrawing prefixes to initiate the DUT's convergence procedure. The procedure for testing protocol convergence performance is as follows:

To measure the protocol convergence time of the DUT, set up the test environment as depicted in , with the Tester directly connected to the DUT.
The Tester withdraws a specified percentage of the total prefixes supported by the DUT, for example, 10%, 20%, up to 100%.
The protocol convergence time is calculated based on DUT logs that record the start and completion times of the convergence process.

Please note that for IGP, proportional prefix withdrawal can be achieved by selectively shutting down interfaces. For instance, if the Tester is connected to ten emulated devices through ten interfaces, each advertising a prefix, withdrawing 10% of prefixes can be accomplished by randomly disabling one interface. Similarly, 20% withdrawal corresponds to shutting down two interfaces, and so forth. This is one suggested method, and other approaches that achieve the same effect should be also acceptable. The protocol convergence time, defined as the duration required for the DUT to complete the convergence process, should be measured from the moment the last “hello” message is received from the emulated device on the disabled interface until SAV rule generation is finalized. To ensure accuracy, the DUT should log the timestamp of the last hello message received and the timestamp when SAV rule updates are complete. The convergence time is the difference between these two timestamps. It is recommended that if the emulated device sends a “goodbye hello” message during interface shutdown, using the receipt time of this message, rather than the last standard hello, as the starting point will provide a more precise measurement, as advised in . Protocol Message Processing Performance: The test for protocol message processing performance uses the same setup illustrated in . This performance metric evaluates the protocol message processing throughput, the rate at which the DUT processes protocol messages. The Tester varies the sending rate of protocol messages, ranging from 10% to 100% of the total link capacity between the Tester and the DUT. The DUT records both the total size of processed protocol messages and the corresponding processing time. The procedure for testing protocol message processing performance is as follows:

To measure the protocol message processing throughput of the DUT, set up the test environment as shown in , with the Tester directly connected to the DUT.
The Tester sends protocol messages at varying rates, such as 10%, 20%, up to 100%, of the total link capacity between the Tester and the DUT.
The protocol message processing throughput is calculated based on DUT logs that record the total size of processed protocol messages and the total processing time.

To compute the protocol message processing throughput, the DUT logs MUST include the total size of the protocol messages processed and the total time taken for processing. The throughput is then derived by dividing the total message size by the total processing time.

Data Plane Performance Objective: Evaluate the data plane performance of the DUT, including both data plane SAV table refresh performance and data plane forwarding performance. Data plane SAV table refresh performance is quantified by the refresh rate, which indicates how quickly the DUT updates its SAV table with new SAV rules. Data plane forwarding performance is measured by the forwarding rate, defined as the total size of packets forwarded by the DUT per second. Data Plane SAV Table Refreshing Performance: The evaluation of data plane SAV table refresh performance uses the same test setup shown in . This metric measures the rate at which the DUT refreshes its SAV table with new SAV rules. The Tester varies the transmission rate of protocol messages, from 10% to 100% of the total link capacity between the Tester and the DUT, to influence the proportion of updated SAV rules and corresponding SAV table entries. The DUT records the total number of updated SAV table entries and the time taken to complete the refresh process. The procedure for testing data plane SAV table refresh performance is as follows:

To measure the data plane SAV table refreshing rate of the DUT, set up the test environment as depicted in , with the Tester directly connected to the DUT.
The Tester sends protocol messages at varying percentages of the total link capacity, for example, 10%, 20%, up to 100%.
The data plane SAV table refreshing rate is calculated based on DUT logs that record the total number of updated SAV table entries and the total refresh time.

To compute the refresh rate, the DUT logs MUST capture the total number of updated SAV table entries and the total time required for refreshing. The refresh rate is then derived by dividing the total number of updated entries by the total refresh time. Data Plane Forwarding Performance: The evaluation of data plane forwarding performance uses the same test setup shown in . The Tester transmits a mixture of spoofed and legitimate traffic at a rate matching the total link capacity between the Tester and the DUT, while the DUT maintains a fully populated SAV table. The ratio of spoofed to legitimate traffic can be varied within a range, for example, from 1:9 to 9:1. The DUT records the total size of forwarded packets and the total duration of the forwarding process. The procedure for testing data plane forwarding performance is as follows:

To measure the data plane forwarding rate of the DUT, set up the test environment as depicted in , with the Tester directly connected to the DUT.
The Tester sends a mix of spoofed and legitimate traffic to the DUT at the full link capacity between the Tester and the DUT. The ratio of spoofed to legitimate traffic may vary, for example, from 1:9 to 9:1.
The data plane forwarding rate is calculated based on DUT logs that record the total size of forwarded traffic and the total forwarding time.

To compute the forwarding rate, the DUT logs must include the total size of forwarded traffic and the total time taken for forwarding. The forwarding rate is then derived by dividing the total traffic size by the total forwarding time.

Inter-domain SAV

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. The inter-domain test cases in this section cover customer interfaces, provider interfaces, lateral peer interfaces, and RS/RS-client-related interfaces when applicable. 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.

SAV for customer-facing ASes in inter-domain symmetric routing scenario. SAV for Customer-facing ASes under an Inter-domain Symmetric Routing Scenario: 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 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:

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 . The Tester is connected to AS 1 and generates test traffic toward the DUT.
Configure AS 1, AS 2, AS 3, the DUT, and AS 5 to establish symmetric routing environment.
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 expected results for this test case are that the DUT blocks spoofed traffic and permits legitimate traffic received from the direction of AS 2. Note that the DUT may also be placed at AS 1 or AS 2 in to evaluate its false positive and false negative rates using the same procedure. In these configurations, the DUT is expected to effectively block spoofed traffic.

SAV for customer-facing ASes in inter-domain asymmetric routing scenario caused by NO_EXPORT. SAV for Customer-facing ASes under an Inter-domain Asymmetric Routing Scenario: presents a test case for SAV in customer-facing ASes under an inter-domain asymmetric routing scenario 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 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:

To evaluate whether the DUT can generate accurate SAV rules under NO_EXPORT-induced asymmetric routing, construct the test environment as shown in . The Tester is connected to AS 1 and generates test traffic toward the DUT.
Configure AS 1, AS 2, AS 3, the DUT, and AS 5 to establish the asymmetric routing scenario.
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.

SAV for customer-facing ASes in the scenario of hidden prefix caused by direct server return (DSR). SAV for Customer-facing ASes under the Scenario of Hidden Prefix: presents a test case for SAV in customer-facing ASes under a Direct Server Return (DSR) 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 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:

To evaluate whether the DUT can generate accurate SAV rules under DSR conditions, construct the test environment as shown in . The Tester is connected to AS 1 and generates test traffic toward the DUT.
Configure AS 1, AS 2, AS 3, the DUT, and AS 5 to establish the DSR scenario.
The Tester sends legitimate traffic (with source addresses in P7 and destination addresses in P2) to AS 2 via the DUT.

The expected results for this test case are that the DUT permits legitimate traffic with source addresses in P7 received from the direction of AS 1. Note that the DUT may also be placed at AS 1 or AS 2 in to evaluate its false positive and false negative rates using the same procedure. In these configurations, the DUT is expected to effectively block spoofed traffic.

SAV for customer-facing ASes in the scenario of reflection attacks. | | | \ \ | |(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. ]]> SAV for Customer-facing ASes under the Reflection Attack Scenario: illustrates a test case for SAV in customer-facing ASes under a reflection attack scenario. In this scenario, a reflection attack using source address spoofing occurs within the DUT's customer cone. 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 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. The procedure for testing SAV under reflection attack conditions is as follows:

To evaluate whether the DUT can generate accurate SAV rules in a reflection attack scenario, construct the test environment as shown in . The Tester is connected to AS 2 and generates test traffic toward the DUT.
Configure AS 1, AS 2, AS 3, the DUT, and AS 5 to simulate the reflection attack scenario.
The Tester sends spoofed traffic (with source addresses in P1 and destination addresses in P5) toward AS 5 via the DUT.

The expected results for this test case are that the DUT blocks spoofed traffic with source addresses in P1 received from the direction of AS 2. Note that the DUT may also be placed at AS 1 or AS 2 in to evaluate its false positive and false negative rates using the same procedure. In these configurations, the DUT is expected to effectively block spoofed traffic.

SAV for customer-facing ASes in the scenario of direct attacks. | | | \ \ | |(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. ]]> SAV for Customer-facing ASes under the Direct Attack Scenario: presents a test case for SAV in customer-facing ASes under a direct attack scenario. In this scenario, a direct attack using source address spoofing occurs within the DUT's customer cone. 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 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. The procedure for testing SAV under direct attack conditions is as follows:

To evaluate whether the DUT can generate accurate SAV rules in a direct attack scenario, construct the test environment as shown in . The Tester is connected to AS 2 and generates test traffic toward the DUT.
Configure AS 1, AS 2, AS 3, the DUT, and AS 5 to simulate the direct attack scenario.
The Tester sends spoofed traffic (with source addresses in P5 and destination addresses in P1) toward AS 1 via the DUT.

The expected results for this test case are that the DUT blocks spoofed traffic with source addresses in P5 received from the direction of AS 2. Note that DUT may also be placed at AS 1 or AS 2 in to evaluate its false positive and false negative rates using the same procedure. In these configurations, the DUT is expected to effectively block spoofed traffic.

SAV for provider-facing ASes in the scenario of reflection attacks. SAV for Provider/Peer-facing ASes under the Reflection Attack Scenario: 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 performing source address spoofing. The servers then send overwhelming responses to the victim, exhausting its network resources. The arrows in 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:

To evaluate whether the DUT can generate accurate SAV rules for provider/peer-facing ASes in a reflection attack scenario, construct the test environment as shown in . The Tester is connected to AS 3 and generates test traffic toward the DUT.
Configure AS 1, AS 2, AS 3, the DUT, and AS 5 to simulate the reflection attack scenario.
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 expected results for this test case are that the DUT blocks spoofed traffic with source addresses in P1 received from the direction of AS 3. Note that the DUT may also be placed at AS 1 or AS 2 in to evaluate its false positive and false negative rates using the same procedure. In these configurations, the DUT is expected to effectively block spoofed traffic.

SAV for provider-facing ASes in the scenario of direct attacks. SAV for Provider/Peer-facing ASes under the Direct Attack Scenario: 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 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:

To evaluate whether the DUT can generate accurate SAV rules for provider-facing ASes in a direct attack scenario, construct the test environment as shown in . The Tester is connected to AS 3 and generates test traffic toward the DUT.
Configure AS 1, AS 2, AS 3, the DUT, and AS 5 to simulate the direct attack scenario.
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 expected results for this test case are that the DUT blocks spoofed traffic with source addresses in P2 received from the direction of AS 3. Note that the DUT may also be placed at AS 1 or AS 2 in to evaluate its false positive and false negative rates using the same procedure. In these configurations, the DUT is expected to effectively block spoofed traffic.

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:

Configure FRR or BGP PIC on the DUT for inter-AS links to AS3 (primary) and AS2 (backup).
Continuously send legitimate and spoofed traffic from AS1 toward DUT.
Trigger a failure on the AS3–DUT link to activate the FRR path via AS2.
Measure false positive and false negative rates during and after switchover.
Restore the AS3 link and verify SAV table consistency.

The expected results for this test case are that the DUT must maintain consistent SAV filtering during FRR events. Transient topology changes should not lead to acceptance of spoofed traffic or unnecessary blocking of legitimate packets.

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:

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.
Generate legitimate and spoofed traffic from AS1 matching both policy-affected and unaffected prefixes.
Observe SAV filtering behavior before and after policy changes.
Modify the routing policy dynamically and measure false positive and false negative rates.

The expected results for this test case are that the DUT should maintain correct SAV filtering regardless of routing policy changes. Legitimate traffic rerouted by policy must not be dropped, and spoofed traffic must not be forwarded during or after policy updates.

Control Plane Performance The test setup, procedure, and metrics for evaluating protocol convergence performance and protocol message processing performance can refer to . Note that the tests for control plane performance of the DUT which performs inter-domain SAV are OPTIONAL. Only DUT which implements the SAV mechanism using an explicit control-plane communication protocol, such as SAV-specific information communication mechanism proposed in should be tested on its control plane performance.

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 .

Resource Utilization When evaluating the DUT for both intra-domain () and inter-domain SAV () functionality, CPU utilization (for both control and data planes) and memory utilization (for both control and data planes) are suggested to record. These metrics should be recorded continuously and be collected separately per plane to facilitate granular performance analysis.