savnet M. Huang
Internet-Draft Huawei Technologies
Intended status: Standards Track W. Cheng
Expires: 22 April 2024 China Mobile
D. Li
Tsinghua University
N. Geng
M. Liu
Huawei Technologies
L. Chen
Zhongguancun Laboratory
C. Lin
New H3C Technologies
20 October 2023
Source Address Validation Table Abstraction and Application
draft-huang-savnet-sav-table-02
Abstract
Existing source address validation (SAV) mechanisms have their own
core data structures for SAV rules which are coupled with the
corresponding underlying implementation. This document defines a
unified abstraction named SAV table that stores all the SAV rules.
The abstraction makes it convenient for engineers or operators to
improve existing SAV mechanisms or properly apply SAV on routers.
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 22 April 2024.
Huang, et al. Expires 22 April 2024 [Page 1]
Internet-Draft SAV Table October 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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. SAV Table Abstraction . . . . . . . . . . . . . . . . . . . . 4
2.1. Validation Process . . . . . . . . . . . . . . . . . . . 5
2.2. Validation Modes . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Mode 1: Interface-based prefix allowlist . . . . . . 6
2.2.2. Mode 2: Interface-based prefix blocklist . . . . . . 6
2.2.3. Mode 3: Prefix-based interface allowlist . . . . . . 7
3. Elimination Actions . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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. For the packets with unwanted source addresses or
arriving at unwanted interfaces, will be considered invalid and
usually be conducted elimination actions on.
Huang, et al. Expires 22 April 2024 [Page 2]
Internet-Draft SAV Table October 2023
There have been many source address validation (SAV) mechanisms such
as ACL-based filtering ([RFC3704]), uRPF-like mechanisms ([RFC3704],
[RFC8704]), etc. ACL rules can act as SAV rules for filtering
unwanted source addresses (possibly spoofed source addresses) at
specific interfaces. Strict uRPF and loose uRPF conducts reverse
looking up in FIB for validating source addresses. Therefore, FIB
entries can somehow be considered as SAV rules.
It can be found that existing SAV mechanisms have their own core data
structures which are coupled with the corresponding underlying
implementation. The coupling induces three problems. First, it is
not easy to perform analysis across different SAV mechanisms because
the SAV rule generation process and the validation process depends on
the underlying implementation. Second, the accuracy of SAV varies
under different application conditions. With diversified data
structure of SAV rules, 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. Third, 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 abstracts the data structure for storing SAV rules as a
unified SAV table. The SAV table is a logical description and not
coupled with underlying implementation. After defining the SAV
table, the document introduces the validation process, validation
modes, and elimination actions. All the descriptions are not bound
to specific implementations, but real implementations must have the
equivalent effects to the abstracted descriptions.
The SAV table abstraction and application introductions can:
* Help engineers easily clarify the design goals of SAV mechanisms.
* Help operators easily learn how to apply SAV in different
scenarios.
How to generate the SAV rules in the SAV table is not the focus of
this document.
1.1. Terminology
SAV rule: The entry specifying the valid incoming interfaces of
specific source addresses or source prefixes.
SAV table: The abstracted data structure that stores SAV rules.
Huang, et al. Expires 22 April 2024 [Page 3]
Internet-Draft SAV Table October 2023
Validation mode: The definition that describes the typical
applications of SAV table. Different modes take effect in different
scales and treat the default prefix differently.
Elimination action: The action taken on the invalid packets that fail
to pass SAV process.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. SAV Table Abstraction
The basic idea of SAV is to check whether a source prefix arrives
from a valid interface of the router. So, there are two dimensions
in a logic SAV table, i.e., source prefix and interface. Section 2
shows the abstraction of SAV table. The prefixes, i.e., Prefix1,
Prefix2, Prefix3, ..., Prefixn, mean the prefixes that the SAV
mechanisms have learned or aim to validate. The interfaces, i.e.,
Intf. 1, Intf. 2, Intf. 3 ..., are the router's interfaces that
enable validation.
Each cell in the table 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 Section 2, 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.
There are two kinds of validity states: "valid" and "invalid". 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. There may be some cases where SAV mechanisms fail to
get enough information for SAV table generation and cannot determine
the validity states of some cells. In these cases, the cells are
suggested to be filled with "valid" instead of "invalid" or a
particularly defined "unknown" state, so that the forwarding of
legitimate packets will not be impacted (e.g., blocked) by mistake.
Huang, et al. Expires 22 April 2024 [Page 4]
Internet-Draft SAV Table October 2023
+-------------------------------------------------+
+ | 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 or invalid
*default: all zero IP address for IPv4 or IPv6
Figure 1: SAV table abstraction
2.1. Validation Process
The validation process is shown in Figure 2. Suppose the router has
learned the SAV table by SAV mechanisms and implemented it in the
data plane. When a packet arrives at the router, the router will
take the source address and the incoming interface of the packet as
the input and look up the table. The validity state that is either
"valid" or "invalid" will be returned after the process.
SAV-enabled Router
+-------------+
packet | look up the |
(src address ---->| implemented |--------> validity
incoming intf.) | SAV table | state
+-------------+
Figure 2: Validation process
2.2. Validation Modes
This section defines validation modes which describes the typical
applications of SAV table. 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 table generation. The
modes can be set before generating the table. 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.
Huang, et al. Expires 22 April 2024 [Page 5]
Internet-Draft SAV Table October 2023
Note that, validation modes do not put restrictions to product
implementations, but the implementation should have the equivalent
effect to the description.
2.2.1. Mode 1: Interface-based prefix allowlist
Mode 1 is an interface-scale mode, i.e., it takes effect on a
configured interface. The interface enabling Mode 1 is maintaining
an interface-based prefix allowlist. Only the source prefixes
recorded in the list will be considered valid, otherwise invalid.
For the interface enabling Mode 1, the corresponding column in the
generated SAV table can be equivalently mapped to a prefix allowlist.
In the column, the prefixes recorded as valid will be put into the
allowlist. Particularly, the default prefix is deterministic to be
"invalid" in the column.
Applying Mode 1 on an interface requires the complete knowledge of
legitimate prefixes connected to the interface. 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. In some cases, it may be
difficult for an interface getting all the legitimate source
prefixes. If not all legitimate prefixes are included in the
allowlist, packets with legitimate source addresses arriving at the
interface may be improperly blocked. 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.
2.2.2. Mode 2: Interface-based prefix blocklist
Mode 2 is also an interface-scale mode, i.e., it takes effect on a
configured interface. An interface cannot enable Mode 1 and Mode 2
at the same time. The interface enabling Mode 2 is maintaining an
interface-based prefix blocklist. The source prefixes recorded in
the list will be considered invalid, otherwise valid. For the
interface enabling Mode 2, the corresponding column in the generated
SAV table can be equivalently mapped to a prefix blocklist. In the
column, the prefixes recorded as invalid will be put into the
blocklist. Particularly, the default prefix is deterministic to be
"valid" in the column.
Huang, et al. Expires 22 April 2024 [Page 6]
Internet-Draft SAV Table October 2023
This mode does not require the complete blocklist. If the packets
with the specific 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.
2.2.3. Mode 3: Prefix-based interface allowlist
Mode 3 is a router-scale mode, i.e., it takes effect on all the SAV-
enabled interfaces except those enabling Mode 1 or Mode 2. The
router enabling Mode 3 is maintaining a specific set of source
prefixes (Notes: usually not include the default prefix) and an
interface allowlist (i.e., a list of legitimate incoming interfaces)
for each of the source prefixes. The packets whose source addresses
are covered by no recorded source prefix will be considered valid. A
packet will also be considered valid, if 1) its source address is
covered by a recorded source prefix and 2) the incoming interface is
also included in the corresponding interface allowlist of the source
prefix. If the source address is covered by a recorded source prefix
but the incoming interface is not included, the validation result
will be "invalid".
Mode 3 focuses on validating/protecting the interested source
prefixes. If some source prefixes are important but there is no
condition to enable Mode 1, Mode 3 can be enabled to 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 arriving at
the interface. Figure 3 shows a comparison of different validation
modes.
+-----------------------------------------------------+
+ Mode | Scale | Treatment of the default prefix +
+-----------------------------------------------------+
+ 1 | interface | invalid +
+ 2 | interface | valid +
+ 3 | router | check its incoming interface +
+-----------------------------------------------------+
Figure 3: A comparison of different validation modes
Huang, et al. Expires 22 April 2024 [Page 7]
Internet-Draft SAV Table October 2023
3. Elimination Actions
After doing validation, the router should update the local validation
statistics. For the packet with invalid state, elimination actions
should be taken on the packet. Simply dropping the packets may not
well satisfy the requirements of operators in different scenarios.
This section suggests to provide flexible actions to invalid packet
just like FlowSpec ([RFC8955], [RFC8956]).
One of the followings elimination actions will be taken:
* "Permit": Forward packets normally though the packets are
considered invalid. This action is useful when operators only
want to monitor the status of source address spoofing in the
network. The "Permit" action can be taken together with the
"Sample" action.
* "Block": 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.
* "Traffic redirect": Redirect the packets to the specified points
(e.g., scrubbing centers) in the network for attack elimination.
The following action is optional:
* "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
elimination actions. Note that, existing techniques like
NetStream or NetFlow can be used for "Sample".
4. 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.
Huang, et al. Expires 22 April 2024 [Page 8]
Internet-Draft SAV Table October 2023
5. IANA Considerations
This document includes no request to IANA.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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>.
6.2. Informative References
[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>.
[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>.
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
RFC 8955, DOI 10.17487/RFC8955, December 2020,
<https://www.rfc-editor.org/info/rfc8955>.
[RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed.,
"Dissemination of Flow Specification Rules for IPv6",
RFC 8956, DOI 10.17487/RFC8956, December 2020,
<https://www.rfc-editor.org/info/rfc8956>.
[I-D.cheng-savnet-proactive-defense-network]
Cheng, W., Geng, N., Li, D., and S. Yue, "Network
Proactive Defense based on Source Address Validation",
Work in Progress, Internet-Draft, draft-cheng-savnet-
proactive-defense-network-01, 19 October 2023,
<https://datatracker.ietf.org/api/v1/doc/document/draft-
cheng-savnet-proactive-defense-network/>.
Authors' Addresses
Huang, et al. Expires 22 April 2024 [Page 9]
Internet-Draft SAV Table October 2023
Mingqing Huang
Huawei Technologies
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 Technologies
Beijing
China
Email: gengnan@huawei.com
Mingxing Liu
Huawei Technologies
Beijing
China
Email: liumingxing7@huawei.com
Li Chen
Zhongguancun Laboratory
Beijing
China
Email: lichen@zgclab.edu.cn
Changwang Lin
New H3C Technologies
Beijing
China
Email: linchangwang.04414@h3c.com
Huang, et al. Expires 22 April 2024 [Page 10]