]> Zhongguancun Laboratory

Beijing China lichen@zgclab.edu.cn

Tsinghua University

Beijing China tolidan@tsinghua.edu.cn

Zhongguancun Laboratory

Beijing China liulb@zgclab.edu.cn

Zhongguancun Laboratory

Beijing China qinlc@zgclab.edu.cn

General [REPLACE] IETF This document defines methodologies for benchmarking the performance of source address validation (SAV) mechanisms. SAV mechanisms are utilized to generate SAV rules to prevent source address spoofing, and have been implemented with many various designs in order to perform SAV in the corresponding scenarios. This document takes the approach of considering a SAV device to be a black box, defining the methodology in a manner that is agnostic to the mechanisms. This document provides a method for measuring the performance of existing and new SAV implementations.

Introduction Source address validation (SAV) is significantly important to prevent source address spoofing. Operators are suggested to deploy different SAV mechanisms based on their deployment network environments. In addition, existing intra-domain and inter-domain SAV mechanisms have problems in operational overhead and accuracy under various scenarios . Intra-domain and inter-domain SAVNET architectures are proposed to guide the design of new intra-domain and inter-domain SAV mechanisms to solve the problems. The benchmarking methodology defined in this document will help operators to get a more accurate idea of the SAV performance when their deployed devices enable SAV and will also help vendors to test the performance of SAV implementation for their devices. This document provides generic methodologies for benchamarking SAV mechanism performance. To achieve the desired functionality, a SAV device may support many SAV mechanisms. This document considers a SAV device to be a black box, regardless of the design and implementation. The tests defined in this document can be used to benchmark a SAV device for SAV accuracy, convergence performance, and control plane and data plane forwarding performance. These tests can be performed on a hardware router, a bare metal server, a virtual machine (VM) instance, or q container instance, which runs as a SAV device. This document is intended for those people who want to measure a SAV device's performance as well as compare the performance of various SAV devices.

Goal and Scope The benchmarking methodology outlined in this draft focuses on two objectives:

• Assessing ''which SAV mechnisms performn best'' over a set of well-defined scenarios.
• Measuring the contribution of sub-systems to the overall SAV systems's performance (also known as ''micro-benchmark'').

The benchmark aims to compare the SAV performance of individual devices, e.g., hardware or software routers. It will showcase the performance of various SAV mechanisms for a given device and network scenario, with the objective of deploying the appropriate SAV mechanism in their network scenario.

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 when, and only when, they appear in all capitals, as shown here.

Terminology Improper Block: The validation results that the packets with legitimate source addresses are blocked improperly due to inaccurate SAV rules. Improper Permit: The validation results that the packets with spoofed source addresses are permitted improperly due to inaccurate SAV rules. SAV Control Plane: The SAV control plane consists of processes including gathering and communicating SAV-related information. SAV Data Plane: The SAV data plane stores the SAV rules within a specific data structure and validates each incoming packet to determine whether to permit or discard it. Host-facing Router: An intra-domain router of an AS which is connected to a host network (i.e., a layer-2 network). Customer-facing Router: An intra-domain router of an AS which is connected to an intra-domain customer network running the routing protocol (i.e., a layer-3 network).

Test Methodology

Test Setup The test setup in general is compliant with . The Device Under Test (DUT) is connected to a Tester and other network devices to construct the network topology introduced in . The Tester is a traffic generator to generate network traffic with various source and destination addresses in order to emulate the spoofing or legitimate traffic. It is OPTIONAL to choose various proportions of traffic and it is needed to generate the traffic with line speed to test the data plane forwarding performance.

Test Setup. | | DUT | |---+ | | | | | | | | +--------------+ | | | +~~~~~~~~~~~~~~~~~~~~~~~~~~+ | | | | +--------------+ | | | | | +---------| Tester |<--------+ | | +--------------+ ]]>

shows the test setup for DUT. In the test network environment, the DUT can be connected to other devices to construct various test scenarios. The Tester can be connected to the DUT directly or by other devices. The connection type between them is determined according to the benchmarking tests in . Besides, the Tester can generate spoofing traffic or legitimate traffic to test the SAV accuracy of DUT in the corresponding scenarios, and it can also generate traffic with line speed to test the data plane forwarding performance of the DUT. In addition, the DUT needs to support logs to record all the test results.

Network Topology and Device Configuration The location where the DUT resides in the network topology affects the accuracy of SAV mechanisms. Therefore, the benchmark MUST put the DUT into different locations in the network to test it. The device in the network topology can have various routing configurations and the generated SAV rules also depends on their configurations. The device configurations used needs to be specified as well. In addition, it is necessary to indicate the device role, such as host-facing router, customer-facing router, and AS border router in the intra-domain network, and the business relationship between ASes in the inter-domain network. The network traffic generated by Tester must specify traffic rate, the proportion of spoofing traffic and legitimate traffic, and the distribution of source addresses, when testing the data plane forwarding performance, as all may affect the testing results.

SAV Performance Indicators This section lists key performance indicators (KPIs) of SAV for overall benchmarking tests. All KPIs MUST be measured in the bencharking scenarios described in . Also, the KPIs MUST be measured from the result output of the DUT.

Proportion of Improper Blocks The proportion of legitimate traffic which is blocked improperly by the DUT across all the legitimate traffic, and this can reflect the SAV accuracy of the DUT.

Proportion of Improper Permits The proportion of spoofing traffic which is permitted improperly by the DUT across all the spoofing traffic, and this can reflect the SAV accuracy of the DUT.

Protocol Convergence Time The protocol convergence time represents the period during which the SAV control plane protocol converges to update the SAV rules when routing changes happen, and it is the time elapsed from the begining of routing change to the completion of SAV rule update. This KPI can indicate the convergence performance of the SAV protocol.

Control Plane Processing Throughput The control plane processing throughput measures the throughput for processing the packets for communicating SAV-related information, and it can indicate the SAV control plane performance of the DUT.

Data Plane Forwarding Rate The data plane forwarding rate measures the SAV data plane forwarding throughput for processing the data plane traffic, and it can indicate the SAV data plane performance of the DUT.

Benchmarking Tests

Intra-domain SAV

SAV Accuracy

Objective Measure the accuracy of the DUT to process legitimate traffic and spoofing traffic across various intra-domain network scenarios including SAV for customer or host Network, SAV for Internet-facing network, and SAV for aggregation-router-facing network, 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.

Test Scenarios

SAV for Customer or Host Network Test Case 1:

SAV for customer or host network in intra-domain symmetric routing scenario.

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. Procedure:

1. 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.
2. Then, the devices including the DUT and Router 1 are configured to form the symmetric routing scenario.
3. 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.

Expected Results: The DUT can block the spoofing traffic and permit the legitimate traffic from Network 1 for this test case. Test Case 2:

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. Procedure:

1. 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.
2. Then, the devices including the DUT, Router 1, and Router 2, are configured to form the asymmetric routing scenario.
3. 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.

Expected Results: The DUT can block the spoofing traffic and permit the legitimate traffic from Network 1 for this test case.

SAV for Internet-facing Network Test Case 1:

SAV for Internet-facing network in intra-domain symmetric routing scenario.

shows the test case of SAV for Internet-facing network in intra-domain symmetric routing scenario. In this test case, the network topology is the same as , and the difference is the location of the DUT in the network topology, where the DUT is connected to Router 1 and the Internet, and the Tester is used to emulate the Internet. The DUT performs Internet-facing SAV instead of customer/host-network-facing SAV. Procedure:

1. 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.
2. Then, the devices including the DUT and Router 1 are configured to form the symmetric routing scenario.
3. 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.

Expected Results: The DUT can block the spoofing traffic and permit the legitimate traffic from the Internet for this test case. Test Case 2:

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. Procedure:

1. 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.
2. Then, the devices including the DUT, Router 1, and Router 2 are configured to form the asymmetric routing scenario.
3. 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.

Expected Results: 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 Test Case 1:

SAV for aggregation-router-facing network in intra-domain symmetric routing scenario.

shows the test case of SAV for aggregation-router-facing network in intra-domain symmetric routing scenario. The test network environment of is the same with . The Tester is connected to Router 1 to emulate the functions of Network 1 to test the SAV accuracy of the DUT facing the direction of Router 1. Procedure:

1. 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.
2. Then, the devices including the DUT and Router 1 are configured to form the symmetric routing scenario.
3. 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.

Expected Results: The DUT can block the spoofing traffic and permit the legitimate traffic from the direction of Router 1 for this test case. Test Case 2:

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. Procedure:

1. 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.
2. Then, the devices including the DUT, Router 1, and Router 2 are configured to form the asymmetric routing scenario.
3. 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.

Expected Results: 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.

Protocol Convergence Performance

Objective Measure the protocol convergence performance of the DUT when route changes happen due to network failures or operator configurations, defined as the protocol convergence time representing the time elapsed from the begining of routing change to the completion of SAV rule update.

Test Scenario

Test setup for protocol convergence performance measurement. | DUT | +-------------+ +-----------+ ]]>

Test Case: shows the test setup for protocol convergence performance measurement. The protocol convergence process of the DUT to update SAV rules launches when the route changes happen. Route changes is the cause of updating SAV rules and may be because of network failures or operator configurations. Therefore, in , the Tester is direclty connects to the DUT and emulates the route changes to launch the convergence process of the DUT by adding or withdrawing the prefixes. Procedure:

1. 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.
2. Then, the Tester proactively withdraws the prefixes in a certern percentage of the overall prefixes supported by the DUT, such as 10%, 20%, ..., 100%.
3. Finally, the protocol convergence time is calculated according to the logs of the DUT about the beginning and completion of the protocol convergence.

Measurements: The logs of the DUT records the begining time of the protocol convergence process and its completion time, and the protocol convergence time is calculated by subtracting the beggining time from the completion time of the protocol convergence process.

Control Plane Performance Test Case: The test of the control plane performance uses the same test setup shown in . The control plane performance measures the control plane 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. Procedure:

1. First, in order to test the control plane 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.
2. 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%.
3. Finally, the control plane processing throughput is calculated according to the logs of the DUT about the overall size of the protocol messages and the overall processing time.

Measurements: The logs of the DUT records the overall size of the protocol messages and the overall processing time, and the control plane processing throughput is calculated by dividing the overall size of the protocol messages by the overall processing time.

Data Plane Forwarding Performance Test Case: The test of the data plane forwarding performance uses the same test setup shown in . The Tester needs to send the traffic which include spoofing and legitimate traffic at the rate of the overall link capacity between the Tester and the DUT, and the DUT build a SAV table with occupying the overall allocated storage space. The ratio of spoofing traffic to legitimate traffic can vary, such as from 1:9 to 9:1. The DUT records the overall size of the forwarded packets and the overall forwarding time. Procedure:

1. 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.
2. 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.
3. 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.

Measurements: 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.

Test Scenario

SAV for Customer-facing ASes Test case 1:

SAV for customer-facing ASes in inter-domain symmetric routing scenario.

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. Procedure:

1. 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.
2. Then, the ASes including AS 1, AS 2, AS 3, the DUT, and AS 5, are configured to form the symmetric routing scenario.
3. 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.

Expected Results: The DUT can block the spoofing traffic and permit the legitimate traffic from the direction of AS 2 for this test case. Test case 2:

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. Procedure:

1. 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.
2. Then, the ASes including AS 1, AS 2, AS 3, the DUT, and AS 5, are configured to form the asymmetric routing scenario.
3. 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.

Expected Results: The DUT can block the spoofing traffic and permit the legitimate traffic from the direction of AS 2 for this test case. Test case 3:

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. Procedure:

1. 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.
2. Then, the ASes including AS 1, AS 2, AS 3, the DUT, and AS 5, are configured to form the scenario of DSR.
3. Finally, the Tester sends the traffic using P3 as source addresses and P2 as destination addresses (legitimate traffic) to AS 2 via the DUT.

Expected Results: The DUT can permit the legitimate traffic with source addresses in P3 from the direction of AS 1 for this test case. Test case 4:

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. Procedure:

1. 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.
2. Then, the ASes including AS 1, AS 2, AS 3, the DUT, and AS 5, are configured to form the scenario of reflection attacks.
3. Finally, the Tester sends the traffic using P1 as source addresses and P5 as destination addresses (spoofing traffic) to AS 5 via the DUT.

Expected Results: The DUT can block the spoofing traffic with source addresses in P1 from the direction of AS 2 for this test case. Test case 5:

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. Procedure:

1. 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.
2. Then, the ASes including AS 1, AS 2, AS 3, the DUT, and AS 5, are configured to form the scenario of direct attacks.
3. Finally, the Tester sends the traffic using P5 as source addresses and P1 as destination addresses (spoofing traffic) to AS 1 via the DUT.

Expected Results: The DUT can block the spoofing traffic with source addresses in P5 from the direction of AS 2 for this test case.

SAV for Provider/Peer-facing ASes Test case 1:

SAV for provider-facing ASes in the scenario of reflection attacks.

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. Procedure:

1. 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.
2. Then, the ASes including AS 1, AS 2, AS 3, the DUT, and AS 5, are configured to form the scenario of reflection attacks.
3. 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.

Expected Results: The DUT can block the spoofing traffic with source addresses in P1 from the direction of AS 3 for this test case. Test case 2:

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. Procedure:

1. 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.
2. Then, the ASes including AS 1, AS 2, AS 3, the DUT, and AS 5, are configured to form the scenario of direct attacks.
3. 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.

Expected Results: The DUT can block the spoofing traffic with source addresses in P2 from the direction of AS 3 for this test case.

Protocol Convergence Performance The test setup, procedure, and measures can refer to .

Control Plane Performance The test setup, procedure, and measures can refer to .

Data Plane Forwarding Performance The test setup, procedure, and measures can refer to .

Reporting Format Each test has a reporting format that contains some global and identical reporting components, and some individual components that are specific to individual tests. The following parameters for test configuration and SAV mechanism settings MUST be reflected in the test report. Test Configuration Parameters:

1. Test device hardware and software versions
2. Device CPU load
3. Network topology
4. Test traffic attributes
5. System configuration (e.g., physical or virtual machine, CPU, memory, caches, operating system, interface capacity)
6. Device configuration (e.g., symmetric routing, NO_EXPORT)
7. SAV mechanism

IANA Considerations This document has no IANA actions.

Security Considerations The benchmarking tests described in this document are limited to the performance characterization of SAV devices in a lab environment with isolated networks. The benchmarking network topology will be an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network.

References Normative References BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704. This document is a republication of RFC 1944 correcting the values for the IP addresses which were assigned to be used as the default addresses for networking test equipment. This memo provides information for the Internet community. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References