Source Address Validation: Use Cases and Gap Analysis
draft-li-sav-gap-analysis-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-10-24 | ||
| 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-sav-gap-analysis-00
Network Working Group D. Li
Internet-Draft J. Wu
Intended status: Informational Tsinghua
Expires: 28 April 2022 M. Huang
Huawei
L. Qin
Tsinghua
N. Geng
Huawei
25 October 2021
Source Address Validation: Use Cases and Gap Analysis
draft-li-sav-gap-analysis-00
Abstract
This document identifies the importance and use cases of source
address validation (SAV) at both intra-AS level and inter-AS level
(see [RFC5210]). However, existing intra-AS and inter-AS SAV
mechanisms, either Ingress ACL filtering [RFC2827], unicast Reverse
Path Forwarding (uRPF) [RFC3704], or Enhanced Feasible-Path uRPF
(EFP-uRPF) [RFC8704] has limitations in scalability or accuracy.
This document provides the gap analysis of the existing SAV
mechanisms followed with some design 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 28 April 2022.
Li, et al. Expires 28 April 2022 [Page 1]
Internet-Draft SAV Use Case & Gap Analysis October 2021
Copyright Notice
Copyright (c) 2021 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 Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Use Case 1: Intra-AS SAV . . . . . . . . . . . . . . . . 6
3.2. Use Case 2: Inter-AS SAV . . . . . . . . . . . . . . . . 7
4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Existing Intra-AS SAV mechanisms . . . . . . . . . . . . 7
4.2. Existing Inter-AS SAV mechanisms . . . . . . . . . . . . 9
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Source Address Validation (SAV) is important for defensing against
source address forgery attacks and accurately tracing back to the
attackers [RFC5210]. Consider that the Internet is extremely large
and complex. It is much difficult to solve the source address
spoofing problem at a single "level" or through a single SAV
mechanism. On the one hand, it is unrealistic to require all
networks to deploy a single SAV mechanism. On the other hand, the
failure of a single SAV mechanism will completely disable SAV.
To address the issue, Source Address Validation Architecture (SAVA)
was proposed [RFC5210]. According to the operating feature of the
Internet, SAVA presents a hierarchical architecture which carries out
source IP address validation at three checking levels, i.e., access
network, intra-AS, and inter-AS. Different levels provide different
Li, et al. Expires 28 April 2022 [Page 2]
Internet-Draft SAV Use Case & Gap Analysis October 2021
granularities of source IP address authenticity. In contrast to the
single-level/point model, SAVA allows incremental deployment of SAV
mechanisms while keeps effective because of its multiple-fence
design. So, enhancing the source IP address validity in all the
three checking levels is of high importance. Furthermore, one or
more independent and loosely-coupled SAV mechanisms can coexist and
cooperate under SAVA, which is friendly to different users (e.g.,
providers) with different policies or considerations. Obviously, the
quality of SAV mechanisms for their target checking levels is key to
the performance of SAV.
There are many SAV mechanisms for different checking levels. For the
access network level, Source Address Validation Improvement (SAVI)
was proposed to force each host to use legitimate source IP address
[RFC7039]. SAVI acts as a purely network-based solution without
special dependencies on hosts. It dynamically binds each legitimate
IP address to a specific port/MAC address and verifies each packet's
source address through the binding relationship. One of the most
attractive features of SAVI is that it supports the maximally fine
granularity of individual IP addresses, which is much finer than the
previous ingress filtering mechanisms.
At the intra-AS level, static Access Control List (ACL) is a typical
solution of SAV. Operators can configure some matching rules to
specify which kind of packets are acceptable (or unacceptable). The
information of ACL should be updated manually so as to keep
consistent with the newest filtering criteria, which inevitably
limits the flexibility and accuracy of SAV. Loose unicast Reverse
Path Forwarding (uRPF) is another solution suitable to intra-AS SAV
[RFC8704]. The routers deploying loose uRPF accept any packets whose
source addresses appear in the local FIB tables. Due to the loss of
directionality, loose uRPF may induce false negative problems.
Strict uRPF was proposed with the consideration of directionality
[RFC8704]. Routers deploying strict uRPF accepts a data packet only
when i) the local FIB contains a prefix encompassing the packet's
source address and ii) the corresponding forwarding action for the
prefix matches the packet's incoming interface. Otherwise, the
packet will be dropped. However, in the scenarios (e.g., multihoming
cases) where data packets are under asymmetric routing, strict uRPF
often results in serious false positive problem [RFC8704].
Li, et al. Expires 28 April 2022 [Page 3]
Internet-Draft SAV Use Case & Gap Analysis October 2021
At the inter-AS level, a combination of Enhanced Feasible-Path uRPF
(EFP-uRPF) and loose uRPF is recommended in [RFC8704]. Particularly,
EFP-uRPF is suggested to be applied on customer interfaces. EPF-uRPF
on an AS can prevent its customers spoofing its upstream ASes' source
addresses but fails in the case of two customers spoofing each other.
On lateral peer interfaces and transit provider interfaces, loose
uRPF is taken. As described previously, false negative problems may
arise.
SAVI provides a complete and maximally fine-grained access
validation, but it is impossible to deploy SAVI on every access point
in the universe. The "fences" at intra- and inter-AS levels are much
important for filtering source address forgery packets that are let
go by access networks. However, there exist some instinctive
drawbacks in the existing SAV mechanisms designed for both the intra-
and inter-AS levels, which leads to inevitable false negative or
false negative problems. A more complete SAV mechanism is required
for both intra- and inter-AS levels.
This document identifies the use cases of intra- and inter-AS SAVs.
These cases will help analyze the instinctive drawbacks of the
existing SAV mechanisms. After that, some design considerations of
overcoming the drawbacks will be presented.
2. Terminology
False positive means the legitimate data packets are dropped
unexpectedly. False negative indicates that the data packets with
spoofed source IP addresses fail to be filtered.
Intra-AS SAV denotes the SAV at intra-AS level, which checks the
source address validity of the data packets (i.e., EAST-WEST traffic)
within an AS. Intra-AS SAV can prevent hosts/routers from spoofing
other source IP blocks in the same AS.
Inter-AS SAV denotes the SAV at inter-AS level, which verifies the
authenticity of the source address of incoming traffic (i.e., NORTH-
SOUTH traffic). Particularly, the traffic arriving from the customer
AS is Northward traffic. The traffic received from the provider/peer
AS is Southward traffic.
Two types of SAV modes are defined, i.e., allowlist and blocklist.
Both of them can be applied to one or more specified interfaces of a
device (router or switch). The data packets with source addresses
appearing in the allowlist and entering the device at the interface
specified by the allowlist will be accepted. The device will drop
the data packets that i) are with source addresses not included in
the allowlist or ii) are with legal source addresses but enter the
Li, et al. Expires 28 April 2022 [Page 4]
Internet-Draft SAV Use Case & Gap Analysis October 2021
device at wrong interfaces. The SAV tables of all uRPF-like
mechanisms belong to allowlist. On the contrary, blocklist only
focus on validity of the source addresses included in the list.
Specifically, the data packets with source addresses included in the
blocklist will be dropped if the arrival interfaces are not expected.
Otherwise, they will be accepted. As for the data packets with
source addresses not included in the blocklist, the device will
accept them all the time, which is the main difference from the SAV
mode of allowlist. Since allowlist and blocklist can work on
specified interfaces of a device, the decision on the SAV mode choice
can be made for an interface adaptively.
3. Use Cases
Figure 1 illustrates the requirements of SAV in both intra- and
inter-AS levels. AS1-AS5 belong to the same customer cone, and AS1
is the stub AS. The topology of AS2 is presented while other ASes'
inner structures are hidden for brevity.
Li, et al. Expires 28 April 2022 [Page 5]
Internet-Draft SAV Use Case & Gap Analysis October 2021
+---------------------+
| AS5 |
+-/\---------------/\-+
/ \
/ \
+-------------------/----------+ \
| AS2 +----------+ | \
| | Router 4 | | +------------+
| +----------+ | | AS4 |--P1''
| / \ | +-----/\-----+
| +----------+ +----------+ | |
| | Router 2 |----| Router 3 | | |
| +----------+ +----------+ | |
| | \ / | | +------------+
| P1' +----------+ P1 | | AS3 |
| | Router 1 | | +-----/\-----+
| +----------+ | /
+------------------\-----------+ /
\ /
\ /
+-----------------------+
| AS1 |
+-----------------------+
P1 is the source IP address prefix of Router3.
P1' is the spoofed P1 by Router2 located in the same AS as Router3.
P1" is the spoofed P1 by Routers located in another AS, i.e., AS4.
Figure 1: Illustration of the requirements of SAV in both intra-
and inter-AS levels
3.1. Use Case 1: Intra-AS SAV
In some scenarios especially very large ASes, hosts/routers in the
same AS may spoof each other's IP addresses. In Figure 1, Router2
spoofs P1 that originates from Router3. With Intra-AS SAV, EAST-WEST
traffic can be checked, and source address spoofing attacks can be
prevented. In the figure, Router1, Router3, and Router4 will drop
the packets with P1' while accept those with P1, when they deploy
Intra-AS SAV mechanisms. Overall, Intra-AS SAV can prevent the
source address spoofing from the same AS.
Li, et al. Expires 28 April 2022 [Page 6]
Internet-Draft SAV Use Case & Gap Analysis October 2021
3.2. Use Case 2: Inter-AS SAV
In Figure 1, AS4 spoofs AS2's IP address prefix, i.e., P1 originated
from Router3. AS5 will receive the Northward traffic from AS2 and
AS4 with legitimate and spoofed IP addresses, respectively. An SAV
mechanism is necessary for AS5 to drop the illegal traffic. From the
view point of Southward traffic, AS1 may also receive spoofed traffic
from AS3 (if AS3 accepts the data packets with source prefix P1").
So, the deployment of SAV on AS1 is also important. Overall, Inter-
AS SAV is necessary and can improve the confidence of the source IP
address validity among ASes.
Furthermore, most of the existing mechanisms applied to Intra-AS or
Inter-AS SAV only take the manner of allowlist. However, a allowlist
may result in false positive when a legitimate IP address does not
appear in the allowlist. That is, allowlist can be incomplete.
In contrast, blocklist can avoid false positive in some way as it
only drop illegal packets currently known by it, even though
incomplete blocklist may result in false negative. The choice
between allowlist and blocklist is important for improving the
accuracy of SAV.
4. Gap Analysis
High accuracy is the basic requirement of any intra- or inter-AS SAV
mechanism. For any SAV mechanism, false positive must be avoided
because legitimate traffic must not be influenced. On that basis,
SAV should also reduce false negative as much as possible. However,
existing SAV mechanisms can not well meet these requirements.
4.1. Existing Intra-AS SAV mechanisms
Operators can configure static ACLs on border nodes to validate
source addresses. The main drawback of ACL-based SAV is high
operational overhead. Limited application scenarios make the ACL-
based method unable to do sufficient SAV on EAST-WEST traffic.
Strict uRPF can generate SAV tables automatically, but it also has
limited application scenarios. Figure 2 illustrates an intra-AS SAV
scenario. In the scenario, AS1 runs strict uRPF. An access network
having IP address prefix 10.0.0.0/15 is attached to two border
routers (Router1 and Router2) of AS1. Due to customer's policy, it
advertises 10.0.0.0/16 to Router1 and 10.1.0.0/16 to Router2. Then,
Router1 and Router2 will advertise the learned IP address prefixes to
other routers in AS1 through intra-domain routing protocols such as
OSPF and IS-IS.
Li, et al. Expires 28 April 2022 [Page 7]
Internet-Draft SAV Use Case & Gap Analysis October 2021
Although customer only advertises 10.0.0.0/16 to Router1, it may send
packets with source IP addresses belonging to 10.1.0.0/16 to Router1
due to load balancing requirements. Suppose the destination node is
Router5. Then the path to destination is
Customer->Router1->Router3->Router5, while the reverse path is
Router5->Router4->Router2->Customer. The round trip routing path is
asymmetric, which cannot be dealt with well by strict uRPF.
Specifically speaking, strict uRPF is faced with the false positive
problem under asymmetric routing scenarios. When Router1/Router3
runs strict uRPF, it learns SAV rules that packets with source
address prefix of 10.0.0.0/16 should enter the router on interface
'#'. Note that strict uRPF takes allowlist in which the rule
<10.0.0.0/16,interface '#> is maintained. When the packets with
source addresses of 10.1.0.0/16 arrive, they will be dropped, which
results in false positive. Similarly, when strict uRPF is deployed
on Router2, the false positive problem still exists.
+-----------------------------------+
| AS1 +----------+ |
| | Router 5 | |
| +----------+ |
| / \ |
| / \ |
| +----------+ +----------+ |
| | Router 3 |------| Router 4 | |
| +----#-----+ +----------+ |
| | | |
| | | |
| +----------+ +----------+ |
| | Router 1 | | Router 2 | |
| +----#-----+ +----------+ |
| \ / |
+--------\---------------/----------+
\ /
10.0.0.0/16 10.1.0.0/16
\ /
+-------------------+
| access network |----10.0.0.0/15
+-------------------+
Figure 2: An intra-AS SAV scenario
Li, et al. Expires 28 April 2022 [Page 8]
Internet-Draft SAV Use Case & Gap Analysis October 2021
4.2. Existing Inter-AS SAV mechanisms
The most popular inter-AS SAV is suggested by [RFC8704], which
combines EFP-uRPF algorithm B and loose uRPF. In particular, EFP-
uRPF algorithm B is for Northward traffic validation. It sacrifices
the directionality of customer interfaces for reducing false positive
cases [RFC8704]. Loose uRPF is for validating Southward traffic on
lateral peer and transit provider interfaces. It sacrifices
directionality of Southward traffic completely. Such a combined
method sacrificing directionality will leads to false negative
sometimes.
Figure 3 illustrates an inter-AS SAV scenario where the above inter-
AS SAV method will fail. In the figure, there are two customer ASes,
i.e., AS1 and AS2. Both of them are attached to a provider AS, i.e.,
AS4. AS4 has a lateral peer and a provider, i.e., AS3 and AS5.
Particularly, AS1 has IP address prefix P1 and advertises it to AS4.
IP address prefix P2 is allocated to AS2 and is also advertised to
AS4. AS3 has IP address prefix P3 and AS5 has IP address prefix P5.
P3 and P5 are also advertised to AS4 through BGP. AS4 deploys SAV
policies, i.e., a combination of EFP-uRPF algorithm B and loose uRPF.
+-----------------+
| AS5 (provider) +---+P5
+--------+--------+
|
| P5[AS5]
P3 |
+----------+ [AS3] +-------\/--------+
|AS3 (peer)+------>+ AS4 |
+-----+----+ +-+/\+-------+/\+-+
| / \
+ / \
P3 P1[AS1]/ \ P2[AS2]
/ \
/ \
+----------------+ +----------------+
P1+---+ AS1 (customer) | | AS2 (customer) +---+P2
+----------------+ +----------------+
Figure 3: An inter-AS SAV scenario
Li, et al. Expires 28 April 2022 [Page 9]
Internet-Draft SAV Use Case & Gap Analysis October 2021
For Northward traffic, AS4 applies EFP-uRPF. Under EFP-uRPF, AS4
will generate allowlists considering P1 and P2 are legitimate on both
the two customer interfaces. When AS1 spoofs IP address prefix P2 of
AS2, the malicious Northward traffic cannot be filtered by AS4. The
same is true when AS2 forges P1 of AS1. That is to say, EPF-uRPF
cannot prevent source address spoofing among customers even though it
only focus on Northward traffic.
For Southward traffic, AS4 deploys loose uRPF for the interfaces of
AS3 and AS5. It will learn that the packets with source addresses of
P3 or P5 can be accepted without validating the specific arrival
interface. Since loose uRPF loses directionality completely, it
obviously will fail in dealing with the source address spoofing
between its lateral peer and provider, i.e., AS3 and AS5.
The instinctive drawbacks of uRPF-like SAV mechanisms come from the
dependence on local FIB and RIB. Local FIB and RIB roughly describe
the relationship among customers, providers, and lateral peers, which
inherently cannot completely restore directionality information of
network traffic. The mismatching of advertised routing information
and real data path (e.g., asymmetric routing) will do reduce the
accuracy of source address validation.
5. Design Considerations
The key to address the instinctive drawbacks of existing intra- and
inter-AS SAV mechanisms is to overcome the limitations of advertised
routing information (expressed as RIB and FIB). That is to say, SAV
should follow the real data forwarding path. To this end, a path
probing method can be taken. Particularly, a router (called a start
router) can proactively send probing packets carrying source
addresses originated locally to all the destinations known by the
router. These packets will be forwarded to each destination along
the real forwarding paths. Routers along the forwarding paths will
relay these packets. At the same time, these traversed routers learn
the pair <source address prefix, interface> infomration for the start
router and could generate SAV tables based on such information. SAV
tables will be used to filter packets to prevent spoofing IP
addresses originated from the start router.
Li, et al. Expires 28 April 2022 [Page 10]
Internet-Draft SAV Use Case & Gap Analysis October 2021
The goal of the design is to achieve zero false positive while trying
best to reduce false negative in both Intra-AS and Inter-AS SAVs. In
practice, it cannot be guaranteed that complete forwarding
information is always learned from all interfaces. Therefore, a
combination of allowlist and blocklist is an alternative way to
improve the accuracy of SAV. If an interface is able to learn the
complete forwarding information, allowlist is fine. Otherwise,
blocklist would be better than allowlist since the former only
validates the legality of learned address information.
Besides high accuracy, designing a practical SAV mechanism needs to
consider many practical issues:
* High scalability. The design should not induce much overhead
(e.g., bandwidth cost of path probing). A fast convergence
performance under environment changes is also important for
improving the scalability in different scales of networks.
* High deployability. SAV tables should be generated automatically
to reduce the operational cost in practice. A strategy of
incremental deployment also needs to be considered.
* High security. The design should include mechanisms to guarantee
the integrity of probing packets. The path probing-based SAV
should be free of Man-in-the-Middle Attack.
6. Security Considerations
TBD
7. Contributors
TBD
8. Acknowledgments
TBD
9. 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>.
Li, et al. Expires 28 April 2022 [Page 11]
Internet-Draft SAV Use Case & Gap Analysis October 2021
[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
Mingqing Huang
Huawei
Beijing
China
Li, et al. Expires 28 April 2022 [Page 12]
Internet-Draft SAV Use Case & Gap Analysis October 2021
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 28 April 2022 [Page 13]