Network Working Group M. Huang
Internet-Draft Huawei
Intended status: Informational W. Cheng
Expires: 7 September 2023 China Mobile
D. Li
Tsinghua University
N. Geng
M. Liu
Huawei
L. Chen
Zhongguancun Laboratory
6 March 2023
Source Address Validation Table Abstraction and Application
draft-huang-savnet-sav-table-01
Abstract
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.
Requirements Language
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].
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/.
Huang, et al. Expires 7 September 2023 [Page 1]
Internet-Draft SAV Table March 2023
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 Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SAV Table Abstraction . . . . . . . . . . . . . . . . . . . . 3
4. Validation Procedure . . . . . . . . . . . . . . . . . . . . 4
5. Validation Modes . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Mode 1: Interface-based prefix allowlist . . . . . . . . 5
5.2. Mode 2: Interface-based prefix blocklist . . . . . . . . 6
5.3. Mode 3: Prefix-based interface allowlist . . . . . . . . 7
6. Available Actions . . . . . . . . . . . . . . . . . . . . . . 8
7. Use Cases of SAV Table . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
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.
Huang, et al. Expires 7 September 2023 [Page 2]
Internet-Draft SAV Table March 2023
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.
2. Terminology
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.
3. SAV Table Abstraction
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
Huang, et al. Expires 7 September 2023 [Page 3]
Internet-Draft SAV Table March 2023
"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
Figure 1: 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.
4. Validation Procedure
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
Huang, et al. Expires 7 September 2023 [Page 4]
Internet-Draft SAV Table March 2023
(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 |
+-----------+ +---------+
Figure 2: The procedure of validating an incoming packet
5. Validation Modes
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.
5.1. Mode 1: Interface-based prefix allowlist
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.
Huang, et al. Expires 7 September 2023 [Page 5]
Internet-Draft SAV Table March 2023
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.
5.2. Mode 2: Interface-based prefix blocklist
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).
Huang, et al. Expires 7 September 2023 [Page 6]
Internet-Draft SAV Table March 2023
Particularly, Mode 2 can become a device-scale mode when all the
interfaces have the same prefix blocklist.
5.3. Mode 3: Prefix-based interface allowlist
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 +
+-----------------------------------------------------+
Figure 3: A comparison of different validation modes
Huang, et al. Expires 7 September 2023 [Page 7]
Internet-Draft SAV Table March 2023
6. Available Actions
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".
+------------------------------------------------------------------+
+ Validity | Available Action | Optional Action +
+------------------------------------------------------------------+
+ valid | permit | sample +
+ invalid | permit, block, rate limit, redirect | sample +
+ unknown | permit, block, rate limit, redirect | sample +
+------------------------------------------------------------------+
Figure 4: Available actions for different validity states
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).
Huang, et al. Expires 7 September 2023 [Page 8]
Internet-Draft SAV Table March 2023
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.
7. Use Cases of SAV Table
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.
8. Security Considerations
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.
9. IANA Considerations
This document includes no request to IANA.
10. Normative References
Huang, et al. Expires 7 September 2023 [Page 9]
Internet-Draft SAV Table March 2023
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/info/rfc8704>.
Authors' Addresses
Mingqing Huang
Huawei
Beijing
China
Email: huangmingqing@huawei.com
Weiqiang Cheng
China Mobile
Beijing
China
Email: chengweiqiang@chinamobile.com
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Mingxing Liu
Huawei
Beijing
China
Email: liumingxing7@huawei.com
Huang, et al. Expires 7 September 2023 [Page 10]
Internet-Draft SAV Table March 2023
Li Chen
Zhongguancun Laboratory
Beijing
China
Email: lichen@zgclab.edu.cn
Huang, et al. Expires 7 September 2023 [Page 11]