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 5 September 2024.¶

Copyright Notice

Copyright (c) 2024 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. The packets with unwanted source addresses or arriving at unwanted interfaces, will be considered invalid and usually be conducted elimination actions on. Only validated packets will continue to be handled 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 unwanted source addresses at specific interfaces ([RFC3704]). However, ACL is not dedicatedly designed for source prefix filtering. There exist performance and scalability issues due to long-key based searching, and usually expert maintenance efforts are required. 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 for 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 prefix, which results in massive false negatives. Overall, existing ACL-based or FIB-based SAVs can only be applied to specific scenarios and cannot be adaptive to various scenarios (e.g., symmetric vs asymmetric).¶

The other limitation is inflexible traffic handling policy. The current common practice is just to silently drop the spoofed packets. We don’t know who benefits from this and who is the source. Further more, the clues of attacks are ignored, which could be very helpful for dealing with DDoS etc.¶

The root cause of the above two limitations is that there is no 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 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, a dedicated SAV table for SAV rules is needed instead of using those derived from other functions, e.g., FIB or ACL. Note that the general SAV capabilities described in this document is decoupled with real implementation. Conforming implementations of this specification may differ, but the SAV outcomes SHOULD be equivalent to the described SAV capabilities. How to generate SAV rules is not the focus of this document.¶

2. Validation Modes

This section describes validation modes. These modes take effect in different scales and treat the default prefix differently. By choosing modes in different scenarios appropriately, the network can be protected as much as possible while not impacting the forwarding of legitimate packets.¶

Validation modes also describe the goal of SAV rule generation. The modes can be set before generating the rules. By specifying validation modes, operators can take appropriate SAV mechanisms matching the modes, and engineers can design new SAV mechanisms to achieve the goal in challenging scenarios.¶

  +-----------------------------------------------------+
  + Mode | Scale     | Treatment of the default prefix  +
  +-----------------------------------------------------+
  + 1    | interface | invalid                          +
  + 2    | interface | valid                            +
  + 3    | router    | check its incoming interface     +
  +-----------------------------------------------------+

                        SAV-enabled router
             +--------------------------------------------+
             |                                            |
packet1--->Mode1---> validity ----+                       |
             |        state1      |                       |
             |                    | if the validity state |
packet2--->Mode2---> validity ----|  is "valid" and       |
             |        state2      |  Mode 3 is enabled    |
             |                    |                       |
             |                    \/                      |
packet3----->|---------------->Mode3---> validity         |
             |                            state3          |
             +--------------------------------------------+

3. Traffic Handling Policies

After doing validation, the router gets the validity state of the incoming packet. For the packet with invalid state, traffic handling policies should be taken on the packet. Simply forwarding or silently dropping may not well satisfy the requirements of operators in different scenarios. This section suggests to provide flexible traffic handling policies to validated packets just like FlowSpec ([RFC8955], [RFC8956]).¶

The followings are the traffic control policies that can be taken. One and only one of the policies will be chosen for an "invalid" validation result.¶

• "Permit": Forward packets normally though the packets are considered invalid. This policy is useful when operators only want to monitor the status of source address spoofing in the network. The "Permit" policy can be taken together with the "Sample" policy.¶

• "Discard": Drop packets directly, which is the common choose 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 do tentative filtering.¶

• "Traffic redirect": Redirect the packets to the specified points (e.g., scrubbing centers) in the network for attack elimination.¶

There are also traffic monitor policies that are optional. One of the useful traffic monitor policies is:¶

• "Sample": Capture the packets with a configurable sampling rate and reports them to remote servers (e.g., security analysis center). The sampled packets can be used for threat awareness and further analysis [I-D.cheng-savnet-proactive-defense-network]. "Sample" can be taken together with any one of the above policies. Note that, existing techniques like NetStream or NetFlow can be used for "Sample".¶

4. Security Considerations

This document focuses on the general SAV capabilities. The generation of SAV rules is not discussed. There may be some security considerations for SAV generation, but it is not in the scope of this document.¶

The "Sample" policy pushes data to remote servers. This function can be achieved by existing techniques like NetStream or NetFlow. The "Sample" policy may induce same security considerations as these techniques, and the corresponding documents have discussed them.¶

5. IANA Considerations

This document includes no request to IANA.¶

Authors' Addresses