| Internet-Draft | SAV Table | March 2023 |
| Huang, et al. | Expires 7 September 2023 | [Page] |
Source address validation (SAV) table consists of SAV rules that are manually configured or automatically generated. The table will take effect in data plane for checking the validity of source addresses. SAV mechanisms may enable SAV tables in data plane using different methods (e.g., ACL or FIB), and these tables are suitable for different application scenarios. This document aims to provide a systematic view of existing SAV tables, which makes it convenient for engineers or operators to improve existing SAV mechanisms or properly apply SAV on routers. The document first examines existing forms of SAV tables and provides a unified abstraction. Then, three validation modes are concluded as well as suggestions for application scenarios. Finally, diversified actions for each validity state are introduced for compliance of different operation requirements.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 8174 [RFC8174].¶
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 7 September 2023.¶
Copyright (c) 2023 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.¶
There have been many source address validation (SAV) mechanisms including ACL-based filtering [RFC3704], uRPF-like mechanisms [RFC8704], 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.¶
Figure 1 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 Figure 1, 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 Section 5.¶
+-------------------------------------------------+ + | Intf 1 | Intf 2 | Intf 3 | ... + +-------------------------------------------------+ + Prefix1 | state_11 | state_12 | state_13 | ... + + Prefix2 | state_21 | state_22 | state_23 | ... + + Prefix3 | state_31 | state_32 | state_33 | ... + + ... | ... | ... | ... | ... + + Prefixn | state_n1 | state_n2 | state_n3 | ... + + default | state_*1 | state_*2 | state_*3 | ... + +-------------------------------------------------+ *state: valid, invalid, or unknown *default: all zero IP address for IPv4 or IPv6
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 Figure 2. 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.¶
Section 5 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 Section 6.¶
validity
packet +-----------+ state +---------+
(src addr., ---->| look up |-------->| conduct |
incoming intf.) | SAV table | | actions |
+-----------+ +---------+
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. Figure 3 shows a comparison of different validation modes.¶
+-----------------------------------------------------+ + Mode | Scale | Treatment of unrecorded prefixes + +-----------------------------------------------------+ + 1 | interface | invalid + + 2 | interface | valid + + 3 | router | valid + +-----------------------------------------------------+
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.¶
+------------------------------------------------------------------+ + Validity | Available Action | Optional Action + +------------------------------------------------------------------+ + valid | permit | sample + + invalid | permit, block, rate limit, redirect | sample + + unknown | permit, block, rate limit, redirect | sample + +------------------------------------------------------------------+
Figure 4 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.¶
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.¶