Benchmarking Methodology for Source Address Validation

Benchmarking Tests

Intra-domain SAV

SAV Accuracy Objective: Evaluate the DUT's accuracy in handling legitimate and spoofing traffic across diverse intra-domain network scenarios, encompassing SAV implementations for customer or host networks, Internet-facing networks, and aggregation-router-facing networks. This assessment is quantified by the ratio of legitimate traffic erroneously blocked by the DUT to the total volume of legitimate traffic, alongside the ratio of spoofing traffic mistakenly allowed by the DUT relative to the total volume of spoofing traffic. In the following, this document introduces the classic scenarios for testing the accuracy of DUT for intra-domain SAV.

SAV for customer or host network in intra-domain symmetric routing scenario. SAV for Customer or Host Network: shows the case of SAV for customer or host network in intra-domain symmetric routing scenario, and the DUT performs SAV as a customer/host-facing router and connects to Router 1 to access the Internet. Network 1 is a customer/host network within the AS, connects to the DUT, and its own prefix is 10.0.0.0/15. The Tester can emulate Network 1 to advertise its prefix in the control plane and generate spoofing and legitimate traffic in the data plane. In this case, the Tester configs to make the inbound traffic destined for 10.0.0.0/15 come from the DUT. The DUT learns the route to prefix 10.0.0.0/15 from the Tester, while the Tester can send outbound traffic with source addresses in prefix 10.0.0.0/15 to the DUT, which emulates the a symmetric routing scenario between the Tester and the DUT. The IP addrsses in this test case is optional and users can use other IP addresses, and this holds true for other test cases as well. The procedure is listed below for testing SAV for customer or host network in intra-domain symmetric routing scenario:

First, in order to test whether the DUT can generate accurate SAV rules for SAV for customer or host network in intra-domain symmetric routing scenario, a testbed can be built as shown in to construct the test network environment. The Tester is connected to the DUT and performs the functions as Network 1.
Then, the devices including the DUT and Router 1 are configured to form the symmetric routing scenario.
Finally, the Tester generates traffic using 10.0.0.0/15 as source addresses (legitimate traffic) and traffic using 10.2.0.0/15 as source addresses (spoofing traffic) to the DUT, respectively. The ratio of spoofing traffic to legitimate traffic can vary, such as from 1:9 to 9:1.

The expected results are that the DUT can block the spoofing traffic and permit the legitimate traffic from Network 1 for this test case.

SAV for customer or host network in intra-domain asymmetric routing scenario. shows the case of SAV for customer or host network in intra-domain asymmetric routing scenario, and the DUT performs SAV as a customer/host-facing router. Network 1 is a customer/host network within the AS, connects to the DUT and Router 1, respectively, and its own prefix is 10.0.0./15. The Tester can emulate Network 1 and performs its control plane and data plane functions. In this case, the Tester configs to make the inbound traffic destined for 10.1.0.0/16 come only from the DUT and the inbound traffic destined for 10.0.0.0/16 to come only from Router 1. The DUT only learns the route to prefix 10.1.0.0/16 from the Tester, while Router 1 only learns the route to the prefix 10.0.0.0/16 from Network 1. Then, the DUT and Router 1 avertise their learned prefixes to Router 2. Besides, the DUT learns the route to 10.0.0.0/16 from Router 2, and Router 1 learns the route to 10.1.0.0/16 from Router 2. The Tester can send outbound traffic with source addresses of prefix 10.0.0.0/16 to the DUT, which emulates the an asymmetric routing scenario between the Tester and the DUT. The procedure is listed below for testing SAV for customer or host network in intra-domain asymmetric routing scenario:

First, in order to test whether the DUT can generate accurate SAV rules for SAV for customer or host network in intra-domain asymmetric routing scenario, a testbed can be built as shown in to construct the test network environment. The Tester is connected to the DUT and Router 1 and performs the functions as Network 1.
Then, the devices including the DUT, Router 1, and Router 2, are configured to form the asymmetric routing scenario.
Finally, the Tester generates traffic using 10.1.0.0/16 as source addresses (spoofing traffic) and traffic using 10.0.0.0/16 as source addresses (legitimate traffic) to the DUT, respectively. The ratio of spoofing traffic to legitimate traffic can vary, such as from 1:9 to 9:1.

The expected results are that the DUT can block the spoofing traffic and permit the legitimate traffic from Network 1 for this test case.

SAV for Internet-facing network in intra-domain symmetric routing scenario. SAV for Internet-facing Network: illustrates the test scenario for SAV in an Internet-facing network within an intra-domain symmetric routing context. In this scenario, the network topology mirrors that of , with the key distinction being the DUT's placement within the network. Here, the DUT is linked to Router 1 and the Internet, with the Tester simulating the Internet's role. The DUT executes Internet-facing SAV, as opposed to customer/host-network-facing SAV. The procedure is listed below for testing SAV for Internet-facing network in intra-domain symmetric routing scenario**:

First, in order to test whether the DUT can generate accurate SAV rules for SAV for Internet-facing network in intra-domain symmetric routing scenario, a testbed can be built as shown in to construct the test network environment. The Tester is connected to the DUT and performs the functions as the Internet.
Then, the devices including the DUT and Router 1 are configured to form the symmetric routing scenario.
Finally, the Tester can send traffic using 10.0.0.0/15 as source addresses (spoofing traffic) and traffic using 10.2.0.0/15 as source addresses (legitimate traffic) to the DUT, respectively. The ratio of spoofing traffic to legitimate traffic can vary, such as from 1:9 to 9:1.

The expected results are that the DUT can block the spoofing traffic and permit the legitimate traffic from the Internet for this test case.

SAV for Internet-facing network in intra-domain asymmetric routing scenario. shows the test case of SAV for Internet-facing network in intra-domain asymmetric routing scenario. In this test case, the network topology is the same with , and the difference is the location of the DUT in the network topology, where the DUT is connected to Router 1 and Router 2 within the same AS, as well as the Internet. The Tester is used to emulate the Internet. The DUT performs Internet-facing SAV instead of customer/host-network-facing SAV. The procedure is listed below for testing SAV for Internet-facing network in intra-domain asymmetric routing scenario**:

First, in order to test whether the DUT can generate accurate SAV rules for SAV for Internet-facing network in intra-domain asymmetric routing scenario, a testbed can be built as shown in to construct the test network environment. The Tester is connected to the DUT and performs the functions as the Internet.
Then, the devices including the DUT, Router 1, and Router 2 are configured to form the asymmetric routing scenario.
Finally, the Tester can send traffic using 10.0.0.0/15 as source addresses (spoofing traffic) and traffic using 10.2.0.0/15 as source addresses (legitimate traffic) to the DUT, respectively. The ratio of spoofing traffic to legitimate traffic can vary, such as from 1:9 to 9:1.

The expected results are that the DUT can block the spoofing traffic and permit the legitimate traffic from the Internet for this test case.

SAV for aggregation-router-facing network in intra-domain symmetric routing scenario. SAV for Aggregation-router-facing Network: depicts the test scenario for SAV in an aggregation-router-facing network within an intra-domain symmetric routing environment. The test network setup in is identical to that of . The Tester is linked to Router 1 to simulate the operations of Network 1, thereby evaluating the SAV accuracy of the DUT as it faces the direction of Router 1. The procedure is listed below for testing SAV for aggregation-router-facing network in intra-domain symmetric routing scenario:

First, in order to test whether the DUT can generate accurate SAV rules for SAV for Internet-facing network in intra-domain symmetric routing scenario, a testbed can be built as shown in to construct the test network environment. The Tester is connected to Router 1 and performs the functions as Network 1.
Then, the devices including the DUT and Router 1 are configured to form the symmetric routing scenario.
Finally, the Tester can send traffic using 10.1.0.0/15 as source addresses (legitimate traffic) and traffic using 10.2.0.0/15 as source addresses (spoofing traffic) to Router 1, respectively. The ratio of spoofing traffic to legitimate traffic can vary, such as from 1:9 to 9:1.

The expected results are that the DUT can block the spoofing traffic and permit the legitimate traffic from the direction of Router 1 for this test case.

SAV for aggregation-router-facing network in intra-domain asymmetric routing scenario. shows the test case of SAV for aggregation-router-facing network in intra-domain asymmetric routing scenario. The test network environment of is the same with . The Tester is connected to Router 1 and Router 2 to emulate the functions of Network 1 to test the SAV accuracy of the DUT facing the direction of Router 1 and Router 2. The procedure is listed below for testing SAV for aggregation-router-facing network in intra-domain asymmetric routing scenario:

First, in order to test whether the DUT can generate accurate SAV rules for SAV for aggregation-router-facing network in intra-domain asymmetric routing scenario, a testbed can be built as shown in to construct the test network environment. The Tester is connected to Router 1 and Router 2 and performs the functions as Network 1.
Then, the devices including the DUT, Router 1, and Router 2 are configured to form the asymmetric routing scenario.
Finally, the Tester generates traffic using 10.1.0.0/16 as source addresses (spoofing traffic) and traffic using 10.0.0.0/16 as source addresses (legitimate traffic) to Router 1, respectively. The ratio of spoofing traffic to legitimate traffic can vary, such as from 1:9 to 9:1.

The expected results are that the DUT can block the spoofing traffic and permit the legitimate traffic from the direction of Router 1 and Router 2 for this test case.

Control Plane Performance Objective: Measure the control plane performance of the DUT, encompassing both protocol convergence performance and protocol message processing performance in response to route changes triggered by network failures or operator configurations. The protocol convergence performance is quantified by the protocol convergence time, which is the duration from the initiation of a routing change to the completion of the SAV rule update. The protocol message processing performance is characterized by the protocol message processing throughput, defined as the total size of protocol messages processed per second.

Test setup for protocol convergence performance measurement. | DUT | +~~~~~~~~~~~~~~~~~~~+ +-------------+ +-----------+ ]]> Protocol Convergence Performance: illustrates the test setup for measuring protocol convergence performance. The protocol convergence process of the DUT, which updates SAV rules, is initiated when route changes occur. These route changes, which necessitate the updating of SAV rules, can result from network failures or operator configurations. Consequently, in , the Tester is directly connected to the DUT and simulates route changes to trigger the DUT's convergence process by adding or withdrawing prefixes. The procedure is listed below for testing the protocol convergence performance:

First, in order to test the protocol convergence time of the DUT, a testbed can be built as shown in to construct the test network environment. The Tester is directly connected to the DUT.
Then, the Tester proactively withdraws the prefixes in a certern percentage of the overall prefixes supported by the DUT, such as 10%, 20%, ..., 100%.
Finally, the protocol convergence time is calculated according to the logs of the DUT about the beginning and completion of the protocol convergence.

Please note that withdrawing prefixes proportionally for IGP can be accomplished by proportionally shutting down interfaces. For instance, the Tester is connected to an emulated network topology where each interface links to an emulated device. Suppose the Tester connects to ten emulated devices through ten interfaces. Initially, these ten emulated devices advertise their prefixes to the DUT. To withdraw 10% of the prefixes, the Tester can randomly disable one interface connected to an emulated device. Similarly, to withdraw 20%, it can shut down two interfaces randomly, and this method applies to other proportions accordingly. This is merely a suggested approach, and alternative methods achieving the same objective are also acceptable. The protocol convergence time, which is the duration required for the DUT to complete the protocol convergence process, should be measured from the moment the last hello message is received on the DUT from the emulated device connected by the disabled interface until the SAV rule generation on the DUT is finalized. To accurately measure the protocol convergence time, the DUT's logs should record the timestamp of receiving the last hello message and the timestamp when the SAV rule update is completed. The protocol convergence time is then determined by calculating the difference between these two timestamps. It is important to note that if the emulated device sends a "goodbye hello" message during the process of shutting down the Tester's interface, using the reception time of this goodbye hello message instead of the last hello message would yield a more precise measurement, as recommended by . Protocol Message Processing Performance: The test of the protocol message processing performance uses the same test setup shown in . The protocol message processing performance measures the protocol message processing throughput to process the protocol messages. Therefore, the Tester can vary the rate for sending protocol messages, such as from 10% to 100% of the overall link capacity between the Tester and the DUT. Then, the DUT records the size of the processed total protocol messages and processing time. The procedure is listed below for testing the protocol message processing performance:

First, in order to test the protocol message processing throughput of the DUT, a testbed can be built as shown in to construct the test network environment. The Tester is directly connected to the DUT.
Then, the Tester proactively sends the protocol messages to the DUT in a certern percentage of the overall link capacity between the Tester and the DUT, such as 10%, 20%, ..., 100%.
Finally, the protocol message processing throughput is calculated according to the logs of the DUT about the overall size of the protocol messages and the overall processing time.

To measure the protocol message processing throughput, the logs of the DUT records the overall size of the protocol messages and the overall processing time, and the protocol message processing throughput is calculated by dividing the overall size of the protocol messages by the overall processing time.

Data Plane Performance Objective: Evaluate the data plane performance of the DUT, encompassing both the data plane SAV table refreshing performance and the data plane forwarding performance. The data plane SAV table refreshing performance is quantified by the data plane SAV table refreshing rate, which indicates the speed at which the DUT updates its SAV table with newly implemented SAV rules. Concurrently, the data plane forwarding performance is measured by the data plane forwarding rate, which represents the total size of packets forwarded by the DUT per second. Data Plane SAV Table Refreshing Performance: The assessment of the data plane SAV table refreshing performance utilizes the identical test configuration depicted in . This performance metric gauges the velocity at which a DUT refreshes its SAV table with new SAV rules. To this end, the Tester can modulate the transmission rate of protocol messages, ranging from 10% to 100% of the total link capacity between the Tester and the DUT. This variation influences the proportion of updated SAV rules and, consequently, the proportion of entries in the SAV table. Subsequently, the DUT logs the total count of updated SAV table entries and the duration of the refreshing process. The procedure is listed below for testing the data plane SAV table refreshing performance:

First, in order to test the data plane SAV table refreshing rate of the DUT, a testbed can be built as shown in to construct the test network environment. The Tester is directly connected to the DUT.
Then, the Tester proactively sends the protocol messages to the DUT in a certern percentage of the overall link capacity between the Tester and the DUT, such as 10%, 20%, ..., 100%.
Finally, the data plane SAV table refreshing rate is calculated according to the logs of the DUT about the overall number of updated SAV table entries and the overall refreshing time.

To measure the data plane SAV table refreshing rate, the logs of the DUT records the overall number of updated SAV table entries and the overall refreshing time, and the data plane SAV table refreshing rate is calculated by dividing the overall number of updated SAV table entries by the overall refreshing time. Data Plane Forwarding Performance: The evaluation of the data plane forwarding performance employs the same test setup illustrated in . The Tester is required to transmit a blend of spoofing and legitimate traffic at a rate equivalent to the total link capacity between the Tester and the DUT, while the DUT constructs a SAV table that utilizes the entire allocated storage space. The proportion of spoofing traffic to legitimate traffic can be adjusted across a range, for example, from 1:9 to 9:1. The DUT then records the aggregate size of the packets forwarded and the total duration of the forwarding activity. The procedure is listed below for testing the data plane forwarding performance:

First, in order to test the data plane forwarding rate of the DUT, a testbed can be built as shown in to construct the test network environment. The Tester is directly connected to the DUT.
Then, the Tester proactively sends the data plane traffic including spoofing and legitimate traffic to the DUT at the rate of the overall link capacity between the Tester and the DUT. The ratio of spoofing traffic to legitimate traffic can vary, such as from 1:9 to 9:1.
Finally, the data plane forwarding rate is calculated according to the logs of the DUT about the overall size of the forwarded traffic and the overall forwarding time.

To measure the data plane forwarding rate, the logs of the DUT records the overall size of the forwarded traffic and the overall forwarding time, and the data plane forwarding rate is calculated by dividing the overall size of the forwarded traffic by the overall forwarding time.

Inter-domain SAV

SAV Accuracy Objective: Measure the accuracy of the DUT to process legitimate traffic and spoofing traffic across various inter-domain network scenarios including SAV for customer-facing ASes and SAV for provider/peer-facing ASes, defined as the proportion of legitimate traffic which is blocked improperly by the DUT across all the legitimate traffic and the proportion of spoofing traffic which is permitted improperly by the DUT across all the spoofing traffic.

SAV for customer-facing ASes in inter-domain symmetric routing scenario. SAV for Customer-facing ASes: presents a test case of SAV for customer-facing ASes in inter-domain symmetric routing scenario. In this test case, AS 1, AS 2, AS 3, the DUT, and AS 5 constructs the test network environment, and the DUT performs SAV as an AS. AS 1 is a customer of AS 2 and the DUT, AS 2 is a customer of the DUT, which 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, and then AS 2 further propagates the route for prefix P1 and P6 to the DUT. Consequently, the DUT can learn the route for prefixes P1 and P6 from AS 1 and AS 2. In this test case, the legitimate path for the traffic with source addresses in P1 and destination addresses in P4 is AS 1->AS 2->AS 4, and the Tester is connected to the AS 1 and the SAV for customer-facing ASes of the DUT is tested. The procedure is listed below for testing SAV for customer-facing ASes in inter-domain symmetric routing scenario:

First, in order to test whether the DUT can generate accurate SAV rules for SAV for customer-facing ASes in inter-domain symmetric routing scenario, a testbed can be built as shown in to construct the test network environment. The Tester is connected to AS 1 and generates the test traffic to the DUT.
Then, the ASes including AS 1, AS 2, AS 3, the DUT, and AS 5, are configured to form the symmetric routing scenario.
Finally, the Tester sends the traffic using P1 as source addresses and P4 as destination addresses (legitimate traffic) to the DUT via AS 2 and traffic using P5 as source addresses and P4 as destination addresses (spoofing traffic) to the DUT via AS 2, respectively. The ratio of spoofing traffic to legitimate traffic can vary, such as from 1:9 to 9:1.

The expected results are that the DUT can block the spoofing traffic and permit the legitimate traffic from the direction of AS 2 for this test case. Note that the locations of the DUT in can be set at AS 1 and AS 2 to evaluate its SAV accuracy according to the procedure outlined above. The expected results are that the DUT will effectively block spoofing traffic.

SAV for customer-facing ASes in inter-domain asymmetric routing scenario caused by NO_EXPORT. presents a test case of SAV for customer-facing ASes in inter-domain asymmetric routing scenario caused by NO_EXPORT configuration. In this test case, AS 1, AS 2, AS 3, the DUT, and AS 5 constructs the test network environment, and the DUT performs SAV as an AS. AS 1 is a customer of AS 2 and the DUT, AS 2 is a customer of the DUT, which is a customer of AS 3, and AS 5 is a customer of both AS 3 and the DUT. AS 1 advertises prefixes P1 to AS 2 and adds the NO_EXPORT community attribute to the BGP advertisement sent to AS 2, preventing AS 2 from further propagating the route for prefix P1 to the DUT. Similarly, AS 1 adds the NO_EXPORT community attribute to the BGP advertisement sent to the DUT, resulting in the DUT not propagating the route for prefix P6 to AS 3. Consequently, the DUT only learns the route for prefix P1 from AS 1 in this scenario. In this test case, the legitimate path for the traffic with source addresses in P1 and destination addresses in P4 is AS 1->AS 2->DUT, and the Tester is connected to the AS 1 and the SAV for customer-facing ASes of the DUT is tested. The procedure is listed below for testing SAV for customer-facing ASes in inter-domain asymmetric routing scenario caused by NO_EXPORT:

First, in order to test whether the DUT can generate accurate SAV rules for SAV for customer-facing ASes in inter-domain asymmetric routing scenario caused by NO_EXPORT, a testbed can be built as shown in to construct the test network environment. The Tester is connected to AS 1 and generates the test traffic to the DUT.
Then, the ASes including AS 1, AS 2, AS 3, the DUT, and AS 5, are configured to form the asymmetric routing scenario.
Finally, the Tester sends the traffic using P1 as source addresses and P4 as destination addresses (legitimate traffic) to the DUT via AS 2 and traffic using P5 as source addresses and P4 as destination addresses (spoofing traffic) to the DUT via AS 2, respectively. The ratio of spoofing traffic to legitimate traffic can vary, such as from 1:9 to 9:1.

SAV for customer-facing ASes in the scenario of direct server return (DSR). presents a test case of SAV for customer-facing ASes in the scenario of direct server return (DSR). In this test case, AS 1, AS 2, AS 3, the DUT, and AS 5 constructs the test network environment, and the DUT performs SAV as an AS. AS 1 is a customer of AS 2 and the DUT, AS 2 is a customer of the DUT, which is 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 the anycast destination IP, the forwarding path is AS 2->DUT->AS 3. The anycast servers in AS 3 receive the requests and tunnel them to the edge servers in AS 1. Finally, the edge servers send the content to the users with source addresses in prefix P3. The reverse forwarding path is AS 1->DUT->AS 2. The Tester sends the traffic with source addresses in P3 and destination addresses in P2 along the path AS 1->DUT->AS 2. The procedure is listed below for testing SAV for customer-facing ASes in the scenario of direct server return (DSR):

First, in order to test whether the DUT can generate accurate SAV rules for SAV for customer-facing ASes in the scenario of DSR, a testbed can be built as shown in to construct the test network environment. The Tester is connected to AS 1 and generates the test traffic to the DUT.
Then, the ASes including AS 1, AS 2, AS 3, the DUT, and AS 5, are configured to form the scenario of DSR.
Finally, the Tester sends the traffic using P3 as source addresses and P2 as destination addresses (legitimate traffic) to AS 2 via the DUT.

Note that in , to direct the return traffic from the edge server to the user to the path AS 1->DUT->AS 2, the document recommends to config static route to direct the traffic with source addresses in P3 and destination addresses in P2 to the DUT. The expected results are that the DUT can permit the legitimate traffic with source addresses in P3 from the direction of AS 1 for this test case. Note that the locations of the DUT in can be set at AS 1 and AS 2 to evaluate its SAV accuracy according to the procedure outlined above. The expected results are that the DUT will effectively block spoofing 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. ]]> depicts the test case of SAV for customer-facing ASes in the scenario of reflection attacks. In this test case, the reflection attack by source address spoofing takes place within DUT's customer cone, where the attacker spoofs the victim's IP address (P1) and sends requests to servers' IP address (P5) that are designed to respond to such requests. The Tester performs the source address spoofing function as an attacker. The arrows in illustrate the commercial relationships between ASes. AS 3 serves as the provider for 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 is listed below for testing SAV for customer-facing ASes in the scenario of reflection attacks:

First, in order to test whether the DUT can generate accurate SAV rules for SAV for customer-facing ASes in the scenario of reflection attacks, a testbed can be built as shown in to construct the test network environment. The Tester is connected to AS 2 and generates the test traffic to the DUT.
Then, the ASes including AS 1, AS 2, AS 3, the DUT, and AS 5, are configured to form the scenario of reflection attacks.
Finally, the Tester sends the traffic using P1 as source addresses and P5 as destination addresses (spoofing traffic) to AS 5 via the DUT.

The expected results are that the DUT can block the spoofing traffic with source addresses in P1 from the direction of AS 2 for this test case. Note that the locations of the DUT in can be set at AS 1 and AS 2 to evaluate its SAV accuracy according to the procedure outlined above. The expected results are that the DUT will effectively block spoofing 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. ]]> presents the test case of SAV for customer-facing ASes in the scenario of direct attacks. In this test case, the direct attack by source address spoofing takes place within the DUT's customer cone, where the attacker spoofs a source address (P5) and directly targets the victim's IP address (P1), overwhelming its network resources. The Tester performs the source address spoofing function as an attacker. The arrows in illustrate the commercial relationships between ASes. AS 3 serves as the provider for 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 is listed below for testing SAV for customer-facing ASes in the scenario of direct attacks**:

First, in order to test whether the DUT can generate accurate SAV rules for SAV for customer-facing ASes in the scenario of direct attacks, a testbed can be built as shown in to construct the test network environment. The Tester is connected to AS 2 and generates the test traffic to the DUT.
Then, the ASes including AS 1, AS 2, AS 3, the DUT, and AS 5, are configured to form the scenario of direct attacks.
Finally, the Tester sends the traffic using P5 as source addresses and P1 as destination addresses (spoofing traffic) to AS 1 via the DUT.

The expected results are that the DUT can block the spoofing traffic with source addresses in P5 from the direction of AS 2 for this test case. Note that the locations of the DUT in can be set at AS 1 and AS 2 to evaluate its SAV accuracy according to the procedure outlined above. The expected results are that the DUT will effectively block spoofing traffic.

SAV for provider-facing ASes in the scenario of reflection attacks. SAV for Provider/Peer-facing ASes: depicts the test case of SAV for provider-facing ASes in the scenario of reflection attacks. In this test case, the attacker spoofs the victim's IP address (P1) and sends requests to servers' IP address (P2) that respond to such requests. The Tester performs the source address spoofing function as an attacker. The servers then send overwhelming responses back to the victim, exhausting its network resources. The arrows in represent the commercial relationships between ASes. AS 3 acts as the provider or lateral peer of the DUT and 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 is listed below for testing SAV for provider-facing ASes in the scenario of reflection attacks:

First, in order to test whether the DUT can generate accurate SAV rules for SAV for provider-facing ASes in the scenario of reflection attacks, a testbed can be built as shown in to construct the test network environment. The Tester is connected to AS 3 and generates the test traffic to the DUT.
Then, the ASes including AS 1, AS 2, AS 3, the DUT, and AS 5, are configured to form the scenario of reflection attacks.
Finally, the Tester sends the traffic using P1 as source addresses and P2 as destination addresses (spoofing traffic) to AS 2 via AS 3 and the DUT.

The expected results are that the DUT can block the spoofing traffic with source addresses in P1 from the direction of AS 3 for this test case. Note that the locations of the DUT in can be set at AS 1 and AS 2 to evaluate its SAV accuracy according to the procedure outlined above. The expected results are that the DUT will effectively block spoofing traffic.

SAV for provider-facing ASes in the scenario of direct attacks. showcases a testcase of SAV for provider-facing ASes in the scenario of direct attacks. In this test case, the attacker spoofs another source address (P2) and directly targets the victim's IP address (P1), overwhelming its network resources. The arrows in represent the commercial relationships between ASes. AS 3 acts as the provider or lateral peer of the DUT and 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 is listed below for testing SAV for provider-facing ASes in the scenario of direct attacks:

First, in order to test whether the DUT can generate accurate SAV rules for SAV for provider-facing ASes in the scenario of direct attacks, a testbed can be built as shown in to construct the test network environment. The Tester is connected to AS 3 and generates the test traffic to the DUT.
Then, the ASes including AS 1, AS 2, AS 3, the DUT, and AS 5, are configured to form the scenario of direct attacks.
Finally, the Tester sends the traffic using P2 as source addresses and P1 as destination addresses (spoofing traffic) to AS1 via AS 3 and the DUT.

The expected results are that the DUT can block the spoofing traffic with source addresses in P2 from the direction of AS 3 for this test case. Note that the locations of the DUT in can be set at AS 1 and AS 2 to evaluate its SAV accuracy according to the procedure outlined above. The expected results are that the DUT will effectively block spoofing traffic.

Control Plane Performance The test setup, procedure, and measures can refer to for testing the protocl convergence performance and protocol message processing performance.

Data Plane Performance The test setup, procedure, and measures can refer to for testing the data plane SAV table refreshing performance and data plane forwarding performance.