General Source Address Validation Capabilities

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 24 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Source address validation (SAV) can detect and prevent source address spoofing on the SAV-enabled routers. When a packet arrives at an interface of the router, the source address of the packet will be validated. Invalid packets - those with unauthorized source addresses or those arriving on incorrect interfaces - are typically dropped. Only validated packets will be processed or forwarded.¶

From the perspective of data plane validation, the SAV capabilities of existing mechanisms have two main limitations.¶

One of them is the deployable scenario limitation. ACL rules can be configured for filtering unauthorized source addresses at specific interfaces [RFC3704]. However, ACL rules are not dedicatedly designed for source prefix filtering. There exist performance and scalability issues due to long-key based searching, and typically requires expert maintenance. Strict uRPF and loose uRPF are two typical FIB-based SAV mechanisms [RFC3704] and are supported by most commercial routers/switches. FIB-based validation brings many benefits compared to ACL-based filtering but also induces some limitations. Strict uRPF is not applicable to asymmetric routing [RFC8704], which exists in various scenarios such as intra-domain multi-homing access, inter-domain interconnection, etc. Under asymmetric routing, a source prefix may have a different incoming interface from the next-hop interface of the matched entry, or the source prefix does not exist in the FIB at all. Loose mode can only block unannounced prefixes, which results in massive false negatives. Overall, existing ACL-based or FIB-based SAV mechanisms can only be applied to specific scenarios and cannot adapt to various ones (e.g., symmetric vs asymmetric).¶

The other limitation is inflexible traffic handling policy. The current common practice of uRPF-based mechanism is just to silently drop the spoofed packets. We don't know who is victim and who is the source. Furthermore, the clues of attacks are ignored, which could be very helpful for dealing with DDoS attacks etc.¶

The root cause of the above two limitations is that there is no mechanism/tool specifically designed for source address filtering. That is, the capabilities of current tools are derived from other functions, e.g., FIB or ACL.¶

This document describes the general SAV capabilities that the data plane of SAV-enabled devices should have. Two kinds of capabilities will be introduced: validation mode and traffic handling policy. Validation modes describe how to apply validation in different scenarios. Traffic handling policies are the policies applied on the non-validated packets. By implementing the general SAV capabilities, the above two limitations of existing mechanisms can be overcome.¶

To achieve accurate and scalable source address validation, dedicated SAV rules are needed instead of just using those derived from other functions, e.g., FIB or ACL.¶

Note that the general SAV capabilities described in this document are decoupled from vendor-specific implementation. Conforming implementations of this specification may differ, but the SAV outcomes SHOULD be equivalent to the described SAV capabilities. And also how to generate SAV rules is not the focus of this document.¶

2. Validation Modes

This section describes four validation modes (IBA-SAV in Section 2.1, IBB-SAV in Section 2.2, PBA-SAV in Section 2.3, PBB-SAV in Section 2.4). These modes take effect in different scales and need corresponding SAV rules to validate spoofing packets. By choosing modes in different scenarios appropriately, the network can be protected as much as possible while not impacting the forwarding of legitimate packets.¶

3. Validation Procedure

IBA-SAV and IBB-SAV are working on interface-level, they must not be enabled on same interface at same time. If they are enabled on same interface, IBB-SAV should be ignored, or be merged into IBA-SAV by removing the prefix listed in IBB-SAV from the allowlist of IBA-SAV. PBA-SAV and PBB-SAV are working on router-level, they are also mutually exclusive with each other, that is, they must not be enabled for a specific source prefix at same time. If so, PBB-SAV should be ignored, or be merged into PBA-SAV by removing the interface listed in PBB-SAV from the allowlist of PBA-SAV. Furthermore, IBA-SAV is the most preferred mode: If an interface has IBA-SAV enabled, traffic on that interface does not need to go through any other modes (IBB-SAV, PBA-SAV or PBB-SAV) , no matter whether they are configured. When the IBB-SAV validation result is "valid", the traffic must also be checked against PBA-SAV or PBB-SAV if those modes are applicable. Figure 1 shows a comparison of different validation modes for dealing with source address validation.¶

  +-----------------------------------------------------------------+
  + Mode | Scale     | SAV rule                | validation result  +
  +-----------------------------------------------------------------+
  + IBA  | interface | interface-based         | invalid if         +
  +      |           | source prefix allowlist | not matched        +
  + IBB  | interface | interface-based         | invalid if         +
  +      |           | source prefix blocklist | matched            +
  + PBA  | router    | prefix-based            | invalid if         +
  +      |           | interface allowlist     | not matched        +
  + PBB  | router    | prefix-based            | invalid if         +
  +      |           | interface blocklist     | matched            +
  +-----------------------------------------------------------------+

The general validation procedure is as follows. The final validity state, either "valid" or "invalid", is returned after the procedure.¶

1. A packet arrives at the router. The source address and incoming interface are recorded, and the initial validity state is set to "valid".¶

2. If IBA-SAV is enabled on the incoming interface, the packet is validated solely against the interface-based prefix allowlist. The procedure returns with the corresponding validity state.¶

3. If IBA-SAV is not enabled but IBB-SAV is enabled on the incoming interface, the packet is validated against the interface-based prefix blocklist. If the result is "invalid", the procedure returns. Otherwise, validation proceeds to the router-level modes.¶

4. If applicable, PBA-SAV and PBB-SAV are evaluated against their respective prefix-based interface allowlist/blocklist rules. The procedure returns if the result is "invalid". Note that for a given source prefix, only one router-level mode should be enabled.¶

4. Traffic Handling Policies

After validation, the router gets the validity state for the incoming packet. For the packet with invalid state, traffic handling policies should be executed for the packet. Simply silently dropping may not well satisfy the requirements of operators in different scenarios. This section suggests to provide flexible traffic handling policies for validated packets similar to FlowSpec [RFC8955] [RFC8956].¶

The following traffic control policies are defined. For a packet with an "invalid" validation result, exactly one of these policies is applied.¶

• "Permit": Forward packets normally even if the packets are considered invalid. This policy is useful when operators only want to monitor the status of source address spoofing in the network. Normally the "Permit" policy is configured together with the traffic monitor policies, e.g. sample.¶

• "Discard": Drop packets directly, which is the common choice of existing SAV mechanisms.¶

• "Rate limit": Enforce an upper bound of traffic rate (e.g., bps or pps) for mitigation of source address spoofing attacks. This policy is helpful while operators want to do tentative filtering.¶

• "Traffic redirect": Redirect the packets to the specified server (e.g., scrubbing center) for attack elimination.¶

There are also traffic monitor policies, which are optional and can be taken together with any other policies (traffic control policies and traffic monitor policies). Some examples of the traffic monitor policies are:¶

• "Count": Count the number of 'invalid' packets for each validation rule.¶

• "Sample": Capture the packets with a configurable sampling rate and report them to remote servers (e.g., security analysis center) for further threat awareness and analysis.¶

The recommended default traffic handling policy combination is: "discard" for traffic control policy plus "count" for traffic monitor policy. The default combination could be modified per system level, per interface level, or configured based on rule level under different validation modes.¶

5. Relationship with Traditional SAV Mechanisms

The FIB-based SAV mechanisms (strict uPRF and loose uRPF, both belongs IBA-SAV -- interface based prefix allowlist) should be upgraded to the new capabilities defined in this document. By doing this, the limitation of strict uRPF in asymmetric routing scenarios can be overcome and new traffic handling policies can be supported, and meanwhile, the router system might not suffer significant performance impact by doing validation based on the new SAV mechanism only, rather than on both of them.¶

Specially, for SAV on open-connected interfaces, operators may want to combine the loose uRPF and SAV IBB-SAV -- loose uRPF allows only announced prefixes as source coming, and additionally SAV IBB-SAV blocks specific source prefixes (e.g. inner prefixes). From data plane point view, Two approaches can be considered:¶

1. Unified IBA-SAV: Maintain a prefix allowlist for the interface by deducting the source prefixes in the IBB-SAV from the prefix allowlist (prefixes in FIB) in the loose uRPF.¶

2. Separate validation: Go through traditional loose uRPF validation first, and then go through the IBB-SAV validation.¶

These two options differ in aspects such as memory space organization and table lookup procedures. Option 1 is preferred if memory space in data plane is allowed.¶

6. Security Considerations

Incorrect SAV rules, whether overly permissive or overly restrictive, can lead to security vulnerabilities. Overly permissive rules may allow spoofed traffic, while overly restrictive rules can cause denial of service for legitimate traffic. Operators should carefully validate SAV rule generation and deployment.¶

Operational Monitoring for Threat Intelligence: SAV rule drop statistics provide valuable first-hand threat intelligence. Unusual drop patterns may indicate active source address spoofing attacks. Operators SHOULD monitor these statistics and feed them into security analytics systems (e.g., via the "Sample" or "Count" policies defined in Section 4) for further threat detection and mitigation.¶

7. IANA Considerations

This document includes no request to IANA.¶

8. Acknowledgements

The authors appreciate the valuable comments from all members of the IETF SAVNET Working Group. We extend a special thanks to Aijun Wang for his guidance and suggestion. We extend a special thanks to Mingxing Liu and Changwang Lin for their feedback and contributions from vendor implemention point of view.¶

9. Contributors

- Mingxing Liu¶

Huawei Technologies¶

China¶

Email: liumingxing7@huawei.com¶

- Changwang Lin¶

New H3C Technologies¶

China¶

email: linchangwang.04414@h3c.com¶

10. References

Authors' Addresses