Advancements in IETF SAVNET WG: Recent Achievements and Future Endeavors

Many attack methods, such as redirection, amplification, and anonymity, exploit source IP address spoofing, making it a significant threat to Internet security. In response network operators use source address validation (SAV) mechanisms to filter packets with spoofed source IP addresses. However, these mechanisms still grapple with validation accuracy and operational efficiency.

In 2022, the Source Address Validation in Intra-domain and Inter-domain Networks Working Group (SAVNET WG) was formed by the Internet Engineering Task Force (IETF) to enhance SAV capabilities across both intra-domain and inter-domain networks, bolstering security measures against such threats.

The SAVNET WG reached a significant milestone at its recent meeting at IETF 117, the fourth SAVNET WG meeting we have held since its inception in 2022, with both the intra-domain and inter-domain SAV problem statement drafts being adopted by the working group.

Watch a recording of the IETF 117 SAVNET WG Meeting.

In this post, I will provide some context around these drafts and discuss the proposed architectures that the working group is now considering to satisfy the requirements of these drafts.

Intra-domain SAV Problem Statement

The recently adopted intra-domain SAV problem statement draft analyzes the weaknesses of existing intra-domain SAV mechanisms such as ACL-based ingress filtering, Strict uRPF, and Loose uRPF for intra-domain SAV. Below is a summary of these weaknesses and the corresponding causes:

• ACL-based ingress filtering has high operational overhead since it requires manual updates when the network topology, IP prefix, or routing changes.
• Strict uRPF would lead to false positives in asymmetric routing scenarios as it conducts SAV rules based on the local FIB, which may not match the real data-plane forwarding paths from the source.
• Loose uRPF would lead to false negatives as it allows packets with source addresses that exist in the FIB without checking their incoming interfaces.

The draft proposes the following requirements for new intra-domain SAV mechanisms:

• Support automatic update: the new SAV mechanism MUST automatically adapt to network dynamics instead of relying on manual updates.
• Improve validation accuracy: the new mechanism MUST avoid false positives in asymmetric routing scenarios and SHOULD reduce false negatives as much as possible.
• Work in incremental/partial deployment: the new mechanism SHOULD provide effective protection when partially deployed in the intra-domain network.
• Increase the speed of convergence: the new intra-domain SAV mechanism MUST update SAV rules quickly to minimize the impacts of false positives and false negatives during convergence.
• Guarantee necessary security: necessary security tools SHOULD be contained in the new intra-domain SAV mechanisms.

Inter-domain SAV Problem Statement

The inter-domain SAV problem statement draft also specifies the weaknesses of inter-domain SAV mechanisms, such as ACL-based ingress filtering, source-based remote triggered black hole (RTBH) filtering, strict uRPF, loose uRPF, FP-uRPF, VRF uRPF, and EFP-uRPF. Below is a summary of these weaknesses and the corresponding causes:

• ACL-based ingress filtering and Source-based RTBH filtering have high operational overhead since both need operators to manually update the ACL rules or the specified source addresses to adapt to the network changes.
• Strict uRPF would lead to false positives when an AS is multi-homed and has asymmetric routes to its provider. This is because it performs SAV only based on the local FIB, which may not include the asymmetric routes of the legitimate packets.
• Loose uRPF would lead to false negatives as it is oblivious to the incoming interfaces of packets.
• FP-uRPF and VRF uRPF would lead to false positives in asymmetric routing scenarios, for example, limited propagation of prefixes, since they perform SAV based on the local RIB, which may not have the prefixes with limited propagation and their permissible incoming interfaces.
• EFP-uRPF would have false positives in the cases of hidden prefixes, for example, direct server return (DSR), because it does not learn the hidden prefixes, which are legitimate source prefixes.

To overcome these weaknesses, the draft recommends that new inter-domain SAV mechanisms need to fully or partially satisfy the following requirements:

• Improve validation accuracy over existing inter-domain SAV mechanisms: The new mechanism SHOULD avoid false positives and permit less spoofed traffic than existing inter-domain SAV mechanisms.
• Work in incremental/partial deployment: The new mechanism SHOULD provide protection for source addresses when it is partially deployed in the Internet.
• Achieve efficient convergence: The new mechanism SHOULD detect network changes and launch the convergence process quickly. It is essential that the new mechanism converges towards accurate SAV rules in a proper manner, effectively reducing false positives and false negatives throughout the convergence process.
• Reduce operational overhead: The new mechanism MUST adapt to dynamic networks and asymmetric routing scenarios automatically.
• Communicate SAV-specific information between ASes: A communication approach between ASes SHOULD be designed to communicate SAV-specific information and it SHOULD secure the communicated information and prevent malicious ASes from generating incorrect or forged information.

In the following, I will provide a brief overview of the two architecture drafts, with the option for readers to delve into the specifics through the provided hyperlinks.

Intra-domain SAVNET Architecture

The intra-domain SAVNET architecture draft:

• Introduces SAV-specific information, architectural components, and the collaborations between them. 
• Provides guidance on how new intra-domain SAV mechanisms can be developed. 

The intra-domain SAVNET architecture shown in Figure 1 comprises a communication channel connecting the Source Entity and Validation Entity, which can be various SAV-equipped devices like routers or servers. The Source Entity serves as the information source, conveying SAV-related information to the Validation Entity. Communication between these entities is facilitated by Source and Validation Speakers via the communication channel, which may involve multiple sessions for transmitting routing and SAV-specific information.

An essential aspect is defining a communication approach for SAV-specific information transmission, including data structure, operations, and timing. During incremental deployment, not all devices support SAV-specific information, so routing information from the local RIB can complement SAV-specific information. The SAV Agent in the Validation Entity consolidates the SAV-specific and routing information and generates SAV rules.

Inter-domain SAVNET Architecture

The inter-domain SAVNET architecture draft:

• Proposes the SAV-specific information and general information for deploying an inter-domain SAV mechanism.
• Defines the architectural components and interconnections between them for generating SAV rules.
• Provides guidance on how new inter-domain SAV mechanisms use SAV-specific information and general information to generate SAV rules.

The inter-domain SAVNET architecture, as depicted in Figure 2, gathers SAV-specific information from other ASes through SAV-specific messages, encompassing AS prefixes and their corresponding legitimate incoming interfaces. This information is crucial for directly generating accurate SAV rules within each AS.

In scenarios where complete SAV-specific information is lacking due to incremental or partial deployment, the architecture can utilize general information, such as routing information from the local RIB and topological information for RPKI ROA Objects and ASPA Objects, to generate SAV rules. The architecture prioritizes SAV-specific information when both SAV-specific and general information are available, as it is tailored for inter-domain SAV and facilitates the creation of more precise SAV rules.

To enable the exchange of SAV-specific information between ASes, a new communication approach is essential, specifying data structure, operations, and timing for message origination, processing, propagation, and termination. Additionally, the SAV Information Base (SIB), managed by the SAV Information Base Manager (SIM), consolidates the information from both SAV-specific and general information.

The Forthcoming Endeavors of SAVNET WG

Moving forward, the SAVNET WG will:

• Improve the intra-domain and inter-domain SAVNET architectures based on feedback during the IETF 117 meeting.
• Optimize the SAVNET YANG model for operating and managing the configurations within the new SAVNET architectures.
• Develop existing and new SAV mechanisms on top of SAVOP.

As a SAVNET WG member, I encourage network practitioners interested in SAV to join the discussion, collaborate with our community, and promote the deployment of SAV.

Dan Li is a professor in the Department of Computer Science and Technology at Tsinghua University.

Libin Liu is an Assistant Researcher at Beijing Zhongguancun Laboratory.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of the Internet Society.