Source Address Validation Table Abstraction and Application

There have been many source address validation (SAV) mechanisms including ACL-based filtering , uRPF-like mechanisms , etc. They aim to manually or automatically generate SAV tables on routers for filtering unwanted source addresses. The SAV tables may be implemented in different ways in data plane and are suitable for different application scenarios. For engineers or operators, it is important to learn how a typical SAV table looks and how to properly use one. However, there is no systematic description of existing SAV tables. Existing SAV mechanisms have their own core data structures which are coupled with the corresponding underlying implementation. It is not easy to perform analysis across different SAV mechanisms. Besides, the accuracy of SAV tables varies under different application conditions. With no unified data structure of SAV table, we cannot easily express or agree on important questions such as which kind of SAV tables can be generated and enabled in the data plane. Thirdly, SAV mechanisms usually take either "permit" action or "block" action on the validated packets. It is sometimes not flexible enough for diversified operation requirements in practice. This document provides a general table abstraction. Any SAV tables of existing mechanisms can be expressed by this abstraction. Then, three validation modes are introduced together with the corresponding generation and application scenarios. Finally, diversified actions are available for each validity state. The actions can be chosen according to specific operation requirements. This document can help clarify the design goals of SAV mechanisms. It also provides guidance to operators on the choice of SAV table modes and SAV mechanisms. Note that, how to generate these SAV tables is not the focus of this document.

SAV rule: The entry indicating an action for the packets matching a specific source address prefix and an incoming interface. SAV table: The data structure that stores SAV rules for the validation of source address validity. Improper block: The unwanted SAV result that the packets with legitimate source addresses are considered invalid. Improper permit: The unwanted SAV result that the packets with spoofed source addresses are considered valid.

For any SAV tables, the basic idea of SAV is to check whether a source prefix arrives from a valid interface. So, there are two dimensions in a logic SAV table, i.e., source prefix and interface. For the packet whose source address and incoming interface are matched in the table, a validity state will be returned, which indicates whether the packet is valid or not. If the state is "valid", the packet is considered legitimate. If the state is "invalid", the packet is considered as carrying a spoofed source address. If the state is "unknown", the validity of the packet cannot be determined directly. shows the abstraction of existing SAV tables. A router will logically maintain only one such table. Each cell indicates the validity state of the corresponding source prefix and interface. For example, suppose a packet with source address P1 arrives at interface Intf1. The validity state for the packet is "state_11" after taking SAV. For the source prefix of "default" in , it means all zero IP address for IPv4 or IPv6, i.e., unrecorded source addresses. The packets with unrecorded source addresses will match the default source prefix. By default, the validity states of unrecorded source addresses for different interfaces (i.e., state_*1, state_*2, state_*3, ...) are all unknown. How to treat the packets with the unrecorded source addresses depends on the configured validation modes, which will described in .

SAV table abstraction The goal of existing SAV mechanisms is to fill such a table. The more accurate and complete the table is, the less improper block and improper permit will happen.

SAV can be enabled on specified interfaces or all interfaces (i.e., the whole router). Only the packets arriving at the enabled interfaces will be validated. The procedure of validating an incoming packet is shown in . There are largely two steps in the procedure. In the first step, the router takes the source address and incoming interface of the packet as the input and looks up the SAV table to get the validity state (i.e., valid, invalid, or unknown). In the second step, one or more actions will be picked and conducted for the packet according to the validity state. will present some validations modes carried out during the process of looking up SAV table. The available actions for the validated packet are introduced in .

This section describes three validation modes based on which the router looks up the SAV table. Briefly, the modes take effect in different scales and treat unknown results differently. By choosing modes in different scenarios appropriately, the network can get well protection without impacting the forwarding of normal packets.

Mode 1 is an interface-scale mode, i.e., it takes effect on a configured interface. When a packet arrives at the interface configured with Mode 1, the SAV table will be looked up to get the validity state of the packet. Particularly, only when the source address/prefix is recorded as valid for the interface in the SAV table, the valid state will be output. If the source address/prefix is not recorded and the validity state is unknown, the packet will be treated same as those with invalid state. Therefore, the interface enabling Mode 1 is equivalently maintaining an interface-based prefix allowlist. Only the source prefixes recorded in the list will be considered valid, otherwise invalid. Applying Mode 1 on an interface requires the complete knowledge of legitimate prefixes connected to the interface. If not all legitimate prefixes are included in the allowlist, packets with legitimate source addresses arriving at the interface may be improperly blocked. In many cases, it is difficult for an interface getting all the source prefixes such that Mode 1 can be taken. For example, the interface with a default route or the interface connecting to the Internet through a provider AS can hardly promise to know all the legitimate source prefixes. Mode 1 is suitable to the interfaces connecting to a subnet, a stub AS, or a customer cone. Such a mode can efficiently prevent the connected network from spoofing source prefixes of other networks. Particularly, Mode 1 can become a device-scale mode, so that all the interfaces have the same prefix allowlist.

Mode 2 is also an interface-scale mode, i.e., it takes effect on a configured interface. When a packet arrives at the interface configured with Mode 2, the SAV table will be looked up to get the validity state of the packet. Particularly, only when the source address/prefix is recorded as invalid for the interface in the SAV table, the invalid state will be output. If the source address/prefix is not recorded and the validity state is unknown, the packet will be treated same as those with valid state. Therefore, the interface enabling Mode 2 is equivalently maintaining an interface-based prefix blocklist. Only the source prefixes recorded in the list will be considered invalid, otherwise valid. The interface enabling Mode 2 will accept any packets whose source addresses are not included in the blocklist of the interface. This mode does not require the complete blocklist. If the packets with the particular source addresses need to be discarded, Mode 2 can be taken. Mode 2 is suitable for proactive filtering and reactive filtering. Usually the source prefixes that are sure to be invalid will be put into the blocklist, which is proactive filtering. Reactive filtering rules are usually installed in DDoS elimination for dropping specific packets. Mode 2 is complementary to Mode 1 with respect to the whole IP address space. For an interface, if the list of all the valid prefixes are known (Mode 1), all the other prefixes in the whole IP space will be invalid (Mode 2). Particularly, Mode 2 can become a device-scale mode when all the interfaces have the same prefix blocklist.

Mode 3 is a router-scale mode, i.e., it takes effect on the whole router. When a packet arrives at the interface configured with Mode 3, the SAV table will be looked up to get the validity state of the packet. Particularly, only when the source address/prefix is recorded as invalid for the interface in the SAV table, the invalid state will be output. If the source address/prefix is not recorded and the validity state is unknown, the packet will be treated same as those with valid state. Therefore, the router enabling Mode 3 is equivalently maintaining a prefix-based interface allowlist for each recorded prefix. Under Mode 3, the router will check whether the packets with recorded source addresses arrive at expected interfaces. If the incoming interface of a packet is included in the legitimate interfaces of the matched source prefix, the validation result is valid. Otherwise, the result is invalid. For the packets with default source prefixes, the result is always valid. Mode 3 focuses on checking whether the learned source prefixes arrive at the expected interfaces. For default source prefixes, it may permit them. When Mode 1 cannot be enabled, Mode 3 can still provide some extent of protection. Note that, Mode 1 and Mode 2 are configured on an interface, while Mode 3 is for the whole router. Thus, there can be multiple modes configured on the same router. For interfaces configured with Mode 1 or Mode 2, Mode 3 will not be conducted for the packets arrving at the interface. shows a comparison of different validation modes.

A comparison of different validation modes

After doing validation, the router will update the local validation statistics and then will take actions based on the validity state of each packet. The available actions include "permit", "block", "rate limit", "traffic redirect" and "sample", etc. "Permit": Forward packets normally. "Block": Drop packets directly. "Rate limit": Enforce an upper bound of traffic rate for mitigation of source address spoofing attacks. Unlike "block" which drops packets directly, "rate limit" takes a safer approach. "Traffic redirect": Redirect the packets to the specified points in the network for attack elimination. "Sample": Capture the specific 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. "Sample" can be taken together with any one of the available actions. Note that, existing techniques like NetStream or NetFlow can be used for "Sample".

Available actions for different validity states shows the available actions for different validity states. Note that, "permit" can also be applied to "Invalid". One possible case is that network operators just want to monitor source address spoofing attacks by sampling instead of blocking them. For the state of "unknown", whether to discard packets depends on the strictness of SAV. To avoid improper block problems, it would be better not to drop "unknown" packets directly (i.e., Mode 2, Mode 3, or Mode 4). For ease of management, some management techniques should be extended to support the operations of SAV table. For example, YANG model for SAV table can be defined to manage SAV rules and collect validation statistics.

The SAV table described in the document supports flexible validation modes and actions. This section provides some possible use cases of the SAV table. Attack elimination or access control: The SAV table can be filled through routing information. If the packets with some source addresses arrives from unwanted directions, the packets are probably with spoofed/unauthorized addresses and should be dropped. Besides, some special SAV rules can also be installed in the SAV table so that the packets with specified source addresses will be blocked. Attack awareness: Conducting SAV based on the SAV table does not always mean packet filtering. The validation can also be used for attack awareness. Through SAV, the possibly malicious packets can be detected and can be reported to remote servers for visualization or further security analysis after sampling. Attack source tracing: The SAV table stores the valid incoming interfaces of source addresses. Therefore, it can help recover the real forwarding path of source address spoofed attacks. Attack source tracing helps achieve near source filtering and vulnerability discovering.

This document focuses on the organization of the core data structure of SAV and device-local SAV operation. The generation of SAV table is not discussed. There may be some security considerations for SAV generation, but it is not in the scope of this document. The "Sample" action pushes data to remote servers. This function can be achieved by existing techniques like NetStream or NetFlow. The "Sample" action may induce same security considerations as these techniques, and the corresponding documents have discussed them.

This document includes no request to IANA.