Distributed Source Address Validation (DSAV) Framework
draft-li-dsav-framework-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Dan Li , Jianping Wu , Mingqing Huang , Lancheng Qin , Nan Geng | ||
| Last updated | 2021-12-11 | ||
| Stream | (None) | ||
| Formats | plain text html xml htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-dsav-framework-00
Network Working Group D. Li
Internet-Draft J. Wu
Intended status: Informational Tsinghua
Expires: 14 June 2022 M. Huang
Huawei
L. Qin
Tsinghua
N. Geng
Huawei
11 December 2021
Distributed Source Address Validation (DSAV) Framework
draft-li-dsav-framework-00
Abstract
This document provides an overall framework of Distributed Source
Address Validation (DSAV) including both intra-AS and inter-AS
levels. It also describes related considerations.
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 2119 [RFC2119].
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 14 June 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires 14 June 2022 [Page 1]
Internet-Draft DSAV Framework December 2021
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. DSAV Framework . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Multicast Tree-like Path Probing . . . . . . . . . . . . 5
3.2. Separate Address Information Advertisement . . . . . . . 7
4. Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Consistency . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Deployability . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Source address validation (SAV) is important to mitigate source
address spoofing and contribute to the Internet security. However,
existing SAV mechanisms have limitations in accuracy. Specifically,
intra-AS SAV mechanisms (e.g. strict uRPF[RFC3704]) have serious
false positive problems in the case of routing asymmetry, while
inter-AS SAV mechanisms (e.g. loose uRPF[RFC3704] and EFP-
uRPF[RFC8704]) have inherent false negative problems. The root cause
of their limitations is that they all achieve SAV based on local
forwarding information base (FIB) or routing information base (RIB),
which may not match the real forwarding direction from the source.
In order to guarantee the accuracy, SAV should follow the real data-
plane forwarding path.
Li, et al. Expires 14 June 2022 [Page 2]
Internet-Draft DSAV Framework December 2021
This document provides a path probing-based framework to generate
accurate SAV tables on routers at both intra-AS and inter-AS levels.
In Distributed Source Address Validation (DSAV) framework, each
router or AS originates probing packets carrying source address
information as well as destination address information. Routers or
ASes along the forwarding path can identify valid incoming interfaces
for related source prefixes and relay new probing packets based on
the destination address information. In particular, multicast tree-
like path probing and separate address information advertisement are
proposed in DSAV to reduce the communication overhead.
This document also describes basic considerations related to DSAV,
including accuracy, consistency, and deployability.
2. Terminology
Distributed Source Address Validation (DSAV)
Some definitions during a path probing process:
* Node: A router or AS in this document.
* Probe initiation node: The node generating original probing
packets.
* On-path node: The node along any of the forwarding paths of
probing packets. On-path nodes with respect to a probing packet
include both the traversed and destination nodes.
* Probing packet: The packet originated from probe initiation nodes
for generating SAV rules along its forwarding paths.
3. DSAV Framework
DSAV is a path probing-based SAV framework for generating SAV rules
on routers. It supports SAV at both the intra-AS and inter-AS
levels. Intra-AS SAV avoids source address spoofing from within AS.
Inter-AS SAV prevents source address spoofing among ASes. Despite of
different application scenarios, DSAVs at the two levels hold the
same key idea. The core workflow of DSAV is briefly described as
follows:
a. A probe initiation node (router or AS) generates probing packets
carrying the source prefixes originated locally and the
destination prefixes reachable by the node.
Li, et al. Expires 14 June 2022 [Page 3]
Internet-Draft DSAV Framework December 2021
b. Each probing packet will be forwarded from the probe initiation
node to the corresponding destination node specified by the
packets.
c. Each on-path node along the forwarding path of the probing packet
will learn the arrival interface of the probing packet. The
learned interface will be considered as a legitimate arrival
interface for data packets with same source IP addresses carried
by the probing packet. The pair <source prefix, interface> will
be taken as SAV rules on on-path nodes.
d. These on-path nodes will enable the learned SAV rule at their
data plane. Any data packets mismatching the SAV rule will be
considered as forged traffic and be dropped immediately.
e. Every node can act as a probe initiation node as well as an on-
path node at the same time. It can send original probing packets
to protect its source addresses from be forged by attackers.
Meanwhile, it can be an on-path node and generates SAV rules for
source addresses of other probe initiation node.
f. The above steps can be executed periodically or when any of
source address information, destination address information, or
forwarding rules change.
Figure 1 illustrates the workflow of DSAV. There are total of four
nodes in the network shown in Figure 1. The network runs some
routing protocols such as OSPF, IS-IS, and BGP. Thus, Prefixes P1
and P2, belonging to Node 1 and Node 3 respectively, are reachable by
all the nodes. Let's consider a path probing process where Node 1 is
the probe initiation node. Node 1 sends a probing packet carrying
source address information (i.e., P1) and destination address
information (i.e., P2). According to the destination address
information, the probe packet will be forwarded through the path of
Node 1 -> Node 2 -> Node 3. Node 2 and Node 3 (i.e., on-path nodes)
will learn the SAV rule for P1, i.e., the pair <P1, interface '#'>.
The rule indicates that data packets with source addresses of P1
should arrive at Node 2 and Node 3 from interface '#'. In this way,
when Node 4 forwards packets with spoofed addresses of P1' to Node 2,
Node 2 will drop them immediately based on the SAV rules.
Li, et al. Expires 14 June 2022 [Page 4]
Internet-Draft DSAV Framework December 2021
+---------------+
| Node 1 +---+P1
+-------+-------+
|
| probing pkt:src_v=[P1],dst_v=[P2]
|
+----------+ +-------#-------+
| Node 4 +------+ Node 2 |
+-----+----+ +-------+-------+
| |
+ | probing pkt:src_v=[P1],dst_v=[P2]
P1' |
+-------#--------+
| Node 3 +---+P2
+----------------+
P1 is the source prefix of Node 1.
P1' is the spoofed P1 by Node 4.
P2 is the source prefix of Node 3.
'#' means the legitimate interface for packets with
source addresses of P1.
Figure 1: An illustration of DSAV
The example in Figure 1 shows a very simple DSAV scenario. In real
networks, there can be lots of nodes as well as a large number of IP
address prefixes. To provide a complete protection for the target
network, every node can act as a probe initiation node and send
probing packets, which will inevitably result in much overhead and
limit the scalability of DSAV. To address the issue, two mechanisms,
i.e., multicast tree-like path probing and separate prefix
information advertisement, are proposed and presented next.
3.1. Multicast Tree-like Path Probing
Consider that the number of probe initiation nodes and their
reachable destination prefixes can be extremely large. The
communication overhead of DSAV is unacceptable for each node sending
an individual probing packet to each reachable destination prefix.
Multicast tree-like path probing is such a mechanism that can greatly
reduce the number of probing packets.
Particularly, a probe initiation node only needs to send one probing
packet to each of its neighboring nodes (Here, packet fragmentation
is not considered for brevity). Each probing packet carries a source
prefix list and a destination prefix list. The source prefix list
includes all the source address prefixes originated locally. The
destination prefix list contains all the reachable destination
Li, et al. Expires 14 June 2022 [Page 5]
Internet-Draft DSAV Framework December 2021
prefixes corresponding to the same next hop in the FIB. Then, the
probing packet is sent to the corresponding next-hop node, i.e., the
on-path node of the probing packet. The on-path node receives the
probing packet and generates SAV rules in the same way as described
previously. After that, the on-path node relays the received probing
packet and sends packets to one or more neighboring nodes according
to the destination prefix list of the received packet. Each probing
packet relayed by the on-path node carries an updated destination
prefix list that is a subset of the original list. The updated list
contains only the destination prefixes of the original list
corresponding to the same neighboring node. Note that, the source
prefix list has no need to be updated. The relayed probing packet
will then continue probing forwarding paths through the updated
destination prefix list. The following on-path nodes will generate
SAV rules accordingly and relay the probing packets until reaching
all the destination nodes. The traversed forwarding paths during a
path probing process look like a multicast tree, and the probe
initiation node of the process is the root of the tree.
+----------+
| Node 1 +---+P1
+----+-----+
| pkt:src_v=[P1],
| dst_v=[P2,P3,P4]
pkt:src_v=[P1], |
+----------+ dst_v=[P4] +-----#-----+
| Node 4 #-------------+ Node 2 |---+P2
+-----+----+ +-----+-----+
| | pkt:src_v=[P1],
+ | dst_v=[P3]
P4 |
+-----#-----+
| Node 3 +---+P3
+-----------+
P1, P2, P3, and P4 are IP address prefixes belonging
to Node 1, 2, 3, and 4, respectively.
Node 1 is the probe initiation node, and the other
nodes are on-path nodes.
'#' means the legitimate interface for the packets with
source addresses of P1.
Figure 2: An example of multicast tree-like path probing
An example of multicast tree-like path probing is shown in Figure 2.
Node 1 is the probe initiation node, and P2~P4 are reachable locally.
Node 1 sends a probing packet to Node 2 with source prefix list [P1]
and destination prefix list [P2, P3, P4]. Node 2 learns the SAV rule
from the probing packet and relays the packet with updated
Li, et al. Expires 14 June 2022 [Page 6]
Internet-Draft DSAV Framework December 2021
destination prefix list to Node 3 and 4. The source prefix list
keeps unchanged, while the destination prefix list is updated
according to the forwarding rules on Node 2. Finally, Node 2~4 learn
and enable the SAV rule, i.e., <P1, interface '#'>.
With multicast tree-like path probing, DSAV can reduce much
unnecessary probing packets in networks and thus consumes less
network resources.
3.2. Separate Address Information Advertisement
Probing packets may have large packet sizes because their source and
destination prefix lists can be very large. Besides, a binding of
prefix information advertisement and path probing will sometimes
induce much unnecessary overhead. For example, a change on either
destination prefix information or forwarding rules will make the
probe initiation node advertise its source address information again
even though no changes happen on source address information at all.
Separate address information advertisement is taken to tackle the
above problem by decoupling address information advertisement and
path probing.
Particularly, a node can be represented by a node ID (e.g., the
router-ID for a router or the ASN for an AS). For each probe
initiation node, its source addresses together with its node ID can
be advertised to other nodes through broadcast or existing underlay
routing protocols (such as OSPF, IS-IS, and BGP). Then, every node
will know the mappings from a node ID to a list of source addresses.
Now, probing packets do not need to carry a long list of source
address prefixes whose field can be replaced with just one source
node ID.
Similarly, the reachable destination information of each probe
initiation node can also be advertised separately, and then the
destination prefix list in a probing packet can be replaced with a
list of destination node IDs. However, the replacement of source and
destination prefix lists may result in false negative problems in
some scenarios where the destination prefixes belonging to the same
destination node have different forwarding paths. Some additional
mechanisms need to be imported into these scenarios.
Li, et al. Expires 14 June 2022 [Page 7]
Internet-Draft DSAV Framework December 2021
4. Accuracy
The goal of DSAV is to achieve high accuracy, i.e., achieve zero
false positive and try best to reduce false negative. Zero false
positive guarantees legitimate traffic not being dropped by mistake,
while reducing false negative means filtering source address forgery
traffic as much as possible.
The accuracy of DSAV is determined by the accuracy of source address
information advertisement, destination address information
advertisement, and path probing results. The completeness of address
information advertisement is important for the accuracy improvement
of DSAV. So, each probe initiation node should discover and
advertise local address information carefully with the help of either
automatic programs or manual configurations. In the case of
incomplete address information advertisement, on-path nodes can take
a remedy method in their data planes, i.e., a combination of
allowlist and blocklist. Allowlist blocks any packets with unknown
source addresses or illegal arrival interfaces, which requires
complete address information advertisement. In contrast, blocklist
only drops packets with known source addresses but illegal arrival
interfaces. Packets with unknown source addresses are accepted under
blocklist. Combining allowlist and blocklist properly is helpful to
eliminate false positive cases.
The accuracy of path probing is also challenging. Path probing
should fully discover all the real forwarding paths of each
destination prefix. Any factor that can affect forwarding should be
considered. Here are three kinds of common forwarding cases:
* FIBs only match destination address prefixes.
* ECMP (Equal-cost multi-path routing) or UCMP (Unequal-cost multi-
path routing). To achieve multi-path routing, hashing functions
are usually taken, which map packet header field values (e.g.,
source/destination IP address, source/destination port number,
protocol number) to candidate next hops. Packets with the same
destination IP address may be forwarding to different next hops.
* ACL redirection. An ACL rule can have multiple match fields, and
the match field of destination IP addresses can be included or not
in an ACL rule. So, similar to ECMP/UCMP, the packets with the
same destination IP address may have different next-hop
interfaces.
Li, et al. Expires 14 June 2022 [Page 8]
Internet-Draft DSAV Framework December 2021
To achieve high accuracy of path probing, either a probe initiation
node or an on-path node need to answer two questions accurately:
which set of next-hop interfaces are for probing and what is the
destination prefix list of the probing packet for each next-hop
interface. Before sending/relaying probing packets, a node should
look up all the local forwarding rules to answer the above two
questions.
5. Consistency
The factors influencing the accuracy of DSAV may change with time.
Such changes will lower the performance of SAV and lead to false
positive/negative problems. The SAV rules generated through DSAV
should be updated in time so as to keep consistent with new source
address information, destination address information or path probing
results. The consistency of DSAV is important for the SAV framework
working well in real networks.
A simple method is to update source/destination address information
and probe forwarding paths periodically. An aging mechanism can also
be used for SAV rules. That is, SAV rules will expire after a period
of time. However, these solutions may take much time before
eliminating false positive/negative. Some quick convergence
mechanisms are necessary to achieve consistency of DSAV in time.
Here are some preliminary ideas for different cases:
* Address information changes. A node sends new information
advertisements immediately upon discovering its local source/
destination address information changes.
* Forwarding path changes. On-path nodes can store the probing
information of recently relayed probing packets. When route
configuration or topology changes, some nodes' forwarding rules
become different. These nodes can generate probing packets for
themselves as well as the nodes whose probing packets were ever
relayed by them. Then, new forwarding paths can be probed
quickly. For the scenarios where fast reroute (FRR) is deployed,
the backup forwarding paths can be pre-probed, and the
corresponding SAV rules can be installed in advance for fast
convergence under failures.
Li, et al. Expires 14 June 2022 [Page 9]
Internet-Draft DSAV Framework December 2021
6. Deployability
It is difficult to ensure that all nodes deploy DSAV simultaneously,
especially at inter-AS level. In this case, each node only learns
partial source address information or incomplete legitimate incoming
interfaces for a source prefix, which can lead to false positive
problems. Therefore, DSAV should support incremental and partial
deployment.
When deployed incrementally or partially, nodes should still achieve
zero false positive and minimize false negative based on incomplete
SAV tables. The process of data-plane SAV is as follows:
* For the source address whose source address information and
incoming interface information are fully learned, nodes can
strictly validate the authenticity by querying <source prefix,
interface> in SAV tables, i.e. allowlist mode.
* For the source address whose source address information or
incoming interface information is only partially learned or even
not learned, nodes should pass those packets by default to avoid
false positive problems, i.e. blocklist mode, since it is hard to
identify the authenticity with incomplete information.
Since inter-AS topology is greatly complex and ASes are managed by
individual network operators, determining wheter the incoming
interface information for a source prefix is learned completely is a
real challenge. Besides, in DSAV framework, neighboring (next-hop)
node plays an important role in the propagation of probing packets,
namely, a node cannot send or receive any probing packet if its
neighboring nodes don't support DSAV. Hence, at inter-AS level, DSAV
recommends incremental deployment by customer cones. This deployment
pattern ensures that each AS learns complete source address
information and incoming interface information for other ASes within
the same customer cone. With the merger of different customer cones
where DSAV is deployed, the deployment scope of DSAV will gradually
expand, and the defense capability against source address spoofing
will gradually increase.
7. Security
TBD
8. Normative References
Li, et al. Expires 14 June 2022 [Page 10]
Internet-Draft DSAV Framework December 2021
[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>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[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>.
[RFC5210] Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams,
"A Source Address Validation Architecture (SAVA) Testbed
and Deployment Experience", RFC 5210,
DOI 10.17487/RFC5210, June 2008,
<https://www.rfc-editor.org/info/rfc5210>.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
"Source Address Validation Improvement (SAVI) Framework",
RFC 7039, DOI 10.17487/RFC7039, October 2013,
<https://www.rfc-editor.org/info/rfc7039>.
[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
Dan Li
Tsinghua
Beijing
China
Email: tolidan@tsinghua.edu.cn
Jianping Wu
Tsinghua
Beijing
China
Email: jianping@cernet.edu.cn
Li, et al. Expires 14 June 2022 [Page 11]
Internet-Draft DSAV Framework December 2021
Mingqing Huang
Huawei
Beijing
China
Email: huangmingqing@huawei.com
Lancheng Qin
Tsinghua
Beijing
China
Email: qlc19@mails.tsinghua.edu.cn
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Li, et al. Expires 14 June 2022 [Page 12]