Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) Gap Analysis, Problem Statement and Requirements
draft-li-savnet-intra-domain-problem-statement-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Dan Li , Jianping Wu , Lancheng Qin , Mingqing(Michael) Huang , Nan Geng | ||
| Last updated | 2022-10-23 | ||
| Replaced by | draft-ietf-savnet-intra-domain-problem-statement | ||
| RFC stream | (None) | ||
| Formats | |||
| 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-savnet-intra-domain-problem-statement-02
Network Working Group D. Li
Internet-Draft J. Wu
Intended status: Informational L. Qin
Expires: 25 April 2023 Tsinghua University
M. Huang
N. Geng
Huawei
22 October 2022
Source Address Validation in Intra-domain Networks (Intra-domain SAVNET)
Gap Analysis, Problem Statement and Requirements
draft-li-savnet-intra-domain-problem-statement-02
Abstract
Source Address Validation in Intra-domain Networks (Intra-domain
SAVNET) aims to make improvements to existing intra-domain Source
Address Validation (SAV). This document provides the gap analysis of
existing intra-domain SAV mechanisms, describes the fundamental
problems, and defines the requirements for improvements.
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/.
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 25 April 2023.
Li, et al. Expires 25 April 2023 [Page 1]
Internet-Draft Intra-domain SAVNET Problem Statement October 2022
Copyright Notice
Copyright (c) 2022 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Improper Block . . . . . . . . . . . . . . . . . . . . . 4
3.2. Vulnerability in Inbound Direction . . . . . . . . . . . 6
3.3. Negligent Edge Router . . . . . . . . . . . . . . . . . . 9
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Inaccurate Validation . . . . . . . . . . . . . . . . . . 10
4.2. High Operational Overhead . . . . . . . . . . . . . . . . 10
4.3. Limited Protection . . . . . . . . . . . . . . . . . . . 10
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Accurate SAV . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Acceptable Overhead . . . . . . . . . . . . . . . . . . . 11
5.3. All-direction Protection . . . . . . . . . . . . . . . . 11
6. Intra-domain SAVNET Scope . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Source Address Validation (SAV) is important for defending against
source address spoofing attacks and accurately tracing back to the
attackers. To be as effective as possible, SAV should be implemented
as close to the source as possible. Given numerous access networks
managed by different operators, it is difficult to require all access
networks to deploy SAV at the source (e.g., SAVI[RFC7039]). When
some access networks do not deploy SAV, intra-domain SAV helps filter
out spoofed packets as close to the source as possible.
Li, et al. Expires 25 April 2023 [Page 2]
Internet-Draft Intra-domain SAVNET Problem Statement October 2022
Ingress filtering [RFC2827] [RFC3704] is the current practice of
intra-domain SAV. Figure 1 shows the typical adoption scenario of
ingress filtering. It is typically deployed at the edge router
connected to a subnet to block spoofing traffic from the subnet. A
subnet refers to a user network attached to the edge router.
+-------------------------------------------------------------+
| AS |
| +----------+ +----------+ |
| | Router 5 +------------+ Router 6 | |
| +----------+ +----------+ |
| / \ \ |
| / \ \ |
| / \ +----------+ |
| +----------+ +----------+ | Router 4 | |
| | Router 1 | | Router 2 | +--------#-+ |
| +------#---+ +--#-------+ / | |
| \ / / | |
| \ / +----------+ Subnet3(p3) |
| \ / | Router 3 | |
| \ / +-----#----+ |
| Subnet1(p1) | |
| Subnet2(p2) |
| |
+-------------------------------------------------------------+
Router 1, 2, 3,and 4 implement ingress filtering at interface #
to block spoofing traffic from subnet 1, 2, and 3.
Figure 1: The typical adoption of ingress filtering.
Static Access Control List (ACL) is a typical implementation of
ingress filtering. Operators can configure some matching rules to
specify which source addresses 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. Strict unicast Reverse
Path Forwarding (uRPF) [RFC3704] is another suitable solution to
achieve ingress filtering in intra-domain networks. Routers
deploying strict uRPF accept a data packet only when i) the local
forwarding information base (FIB) contains a prefix encompassing the
packet's source address and ii) the corresponding forwarding next hop
for the prefix matches the packet's incoming direction. Otherwise,
the packet will be blocked. However, in the scenario where data
packets are under asymmetric routing, strict uRPF often improperly
blocks legitimate traffic. Feasible uRPF and loose uRPF are two
other alternative implementations of ingress filtering, but their
Li, et al. Expires 25 April 2023 [Page 3]
Internet-Draft Intra-domain SAVNET Problem Statement October 2022
filtering rules are very loose and generally permit all (spoofing)
packets with source addresses in the local FIB. Therefore, a new
intra-domain SAV mechanism is required to improve accuracy upon
current ones.
This document provides the gap analysis of existing intra-domain SAV
mechanisms, describes their fundamental problems, and defines the
requirements for improvements.
2. Terminology
SAV: Source Address Validation, i.e. validating the authenticity of a
packet's source IP address.
SAV rule: The rule generated by intra-domain SAV mechanisms that
determines valid incoming interfaces for a specific source prefix.
SAV table: The data structure that stores SAV rules on the data
plane. The router queries its local SAV table to validate the
authenticity of source addresses.
Improper block: The packets with legitimate source IP addresses are
blocked improperly due to inaccurate SAV rules.
Improper permit: The packets with spoofed source IP addresses are
permitted improperly due to inaccurate SAV rules.
3. Gap Analysis
3.1. Improper Block
Existing intra-domain SAV mechanisms can improperly block traffic
with legitimate source addresses due to their technical limitations.
For example, figure 2 illustrates an intra-domain scenario of multi-
homed subnet.
In this scenario, Subnet 1 is attached to two edge routers, i.e.
Router 1 and Router 2. Although Subnet 1 owns prefix 10.0.0.0/15,
Subnet 1 expects traffic destined for 10.1.0.0/16 to come only from
Router 1 and traffic destined for 10.0.0.0/16 to come only from
Router 2, for traffic engineering or load balance purposes. To this
end, Router 1 only learns the sub prefix 10.1.0.0/16 from Subnet 1,
while Router 2 only learns the other sub prefix 10.0.0.0/16 from
Subnet 1. Then, Router 1 and Router 2 advertise the learned sub
prefix to other routers in the AS through intra-domain routing
protocols such as OSPF or IS-IS. Finally, Router 1 learns the route
to 10.0.0.0/16 from Router 5, and Router 2 also learns the route to
10.1.0.0/16 from Router 5. Although Subnet 1 only expects traffic
Li, et al. Expires 25 April 2023 [Page 4]
Internet-Draft Intra-domain SAVNET Problem Statement October 2022
destined for 10.0.0.0/16 to come from Router 2, it still sends
packets with source addresses of prefix 10.0.0.0/16 to Router 1,
resulting in routing asymmetry.
+-------------------------------------------------------------+
| AS |
| +----------+ |
| | Router 5 | |
| FIB for Router 1 +----------+ FIB for Router 2 |
| Dest Next_hop / \ Dest Next_hop |
| 10.1.0.0/16 Subnet 1 / \ 10.0.0.0/16 Subnet 1 |
| 10.0.0.0/16 Router 5 / \/ 10.1.0.0/16 Router 5 |
| +----------+ +----------+ |
| | Router 1 | | Router 2 | |
| +-----+#+--+ +-+#+------+ |
| /\ / |
| Outgoing traffic with \ / Incoming traffic with |
| source IP addresses \ / destination IP addresses |
| of 10.0.0.0/16 \ \/ of 10.0.0.0/16 |
| +----------+ |
| | Subnet 1 | |
| +----------+ |
| (10.0.0.0/15 ) |
| |
+-------------------------------------------------------------+
If Router 1 and 2 apply ingress filtering at interface #:
- Strict uRPF has improper block problem;
- ACL-based SAV requires manual update given prefix or topology
update in Subnet 1
Figure 2: Asymmetric routing in multi-homed subnet scenario.
Li, et al. Expires 25 April 2023 [Page 5]
Internet-Draft Intra-domain SAVNET Problem Statement October 2022
If Router 1 applies strict uRPF at the subnet interface, the SAV rule
is that Router 1 only accepts packets with source addresses of
10.1.0.0/16 from Subnet 1. Therefore, when Subnet 1 sends packtes
with source addresses of 10.0.0.0/16 to Router 1, strict uRPF at
Router 1 will improperly block these legitimate packets. Similarly,
when Router 2 with strict uRPF deployed receives packets with source
addresses of prefix 10.1.0.0/16 from Subnet 1, it will also
improperly block these legitimate packets. If Router 1 and 2 apply
ACL-based SAV at interfaces '#', it requires manual update given
prefix or topology update in Subnet 1. Once the network operator
does not update the ACL in time, resulting in the ACL status is
inconsistent with the routing status, it will cause improper block
problems as well. Overall, strict uRPF has serious improper block
problem in the case of routing asymmetry, and ACL-based SAV needs
high operational overhead in dynamic networks.
3.2. Vulnerability in Inbound Direction
As shown in Figure 1, ingress filtering is typically deployed at the
edge router connected to a subnet and only works for outbound traffic
(traffic from the subnet to other networks) but does not work for
inbound traffic (traffic from other networks to the subnet). It
prevents the deployed area from sending spoofing traffic, but does
not protect the deployed area from source address spoofing attacks.
Li, et al. Expires 25 April 2023 [Page 6]
Internet-Draft Intra-domain SAVNET Problem Statement October 2022
+ Spoofing traffic with source addresses
| of p1, p2, or p3
+--------------|----------------------------------------------+
| | AS |
| +--\/------+ +----------+ |
| | Router 5 +------------> Router 6 | |
| +----------+ +----------+ |
| / \ \ |
| / \ \/ |
| \/ \/ +----------+ |
| +----------+ +----------+ | Router 4 | |
| | Router 1 | | Router 2 | +--------#-+ |
| +------#---+ +--#-------+ / | |
| \ / \/ \/ |
| \ / +----------+ Subnet3(p3) |
| \ / | Router 3 | |
| \/ \/ +-----#----+ |
| Subnet1(p1) | |
| \/ |
| Subnet2(p2) |
+-------------------------------------------------------------+
Spoofing traffic can easily enter from inbound direction
without being detected by ingress filtering
Figure 3: Spoofing from inbound direction.
Figure 3 shows a scenario of source address spoofing from inbound
direction. Although the AS has applied ingress filtering at all edge
routers, the spoofing traffic (even with forged intra-domain source
addresses) can easily enter from inbound direction due to the lack of
inbound SAV.
In practice, it is often a challenge to apply intra-domain SAV to all
edge routers. For example, the improper block problem described in
Section 3.1 prevents ingress filtering from being implemented in some
multi-homed scenarios. In addition, there are also some routers that
cannot support SAV due to their versions, vendors, and capabilities.
Besides, a large intra-domain network (such as the China Education
Research Network) can be managed by multiple administrators (e.g.,
subnets in the education network are administered by different
campuses), and some administrators may not be willing to deploy SAV.
As a result, incremental and partial deployment of intra-domain SAV
is common. However, when ingress filtering is partially deployed,
the effectiveness of intra-domain SAV will be significantly degraded.
Li, et al. Expires 25 April 2023 [Page 7]
Internet-Draft Intra-domain SAVNET Problem Statement October 2022
+-------------------------------------------------------------+
| AS |
| +----------+ +----------+ |
| | Router 5 +------------> Router 6 | |
| +----------+ +----------+ |
| / /\ \ |
| / \ \/ |
| / \ +----------+ |
| +----------+ +----------+ | Router 4 | |
| | Router 1 | | Router 2 | +--------#-+ |
| +----------+ +----------+ / | |
| \ /\ / \/ |
| \ / Spoofing +----------+ Subnet3(p3) |
| \ / traffic | Router 3 | | |
| \ / +-----#----+ + |
| Subnet1(p1) | Reflector |
| | | |
| + Subnet2(p2)-+Victim |
| Attacker (spoof p2) |
+-------------------------------------------------------------+
Partial deployment scenario:
- Router 3 and 4 apply ingress filtering
- Router 1 and 2 do not deploy ingress filtering
Figure 4: Reflection attack in a partial deployment scenario.
Figure 4 describes a reflection attack in a partial deployment
scenario. Router 1, 2, 3, and 4 are edge routers, each connected to
a subnet. Router 5 and 6 are two core routers that are responsible
for transmitting traffic. Assume only Router 3 and 4 apply ingress
filtering at subnet interfaces, and Router 1 and 2 do not apply
ingress filtering. In this case, although subnets that deploy
ingress filtering at the edge router (e.g., Subnet 2 and Subnet 3)
cannot forge source addresses of other subnets, they are still
vulnerable to reflection attacks from other non-deploying subnets
(e.g., Subnet 1).
For example, to conduct a reflection attack to the victim in Subnet
2, the attacker in Subnet 1 can send a forged request with victim's
source address to the reflector in Subnet 3. Since Router 2 does not
apply ingress filtering, the forged request will successfully enter
the intra-domain network and be forwarded to the reflector. When
receiving the forged request, Router 4 will also permit the request
due to the lack of inbound SAV. In the end, the reflector will
receive the forged request and generate a large number of responses
to the victim, and the reflection attack succeeds.
Li, et al. Expires 25 April 2023 [Page 8]
Internet-Draft Intra-domain SAVNET Problem Statement October 2022
3.3. Negligent Edge Router
A negligent edge router with ingress filtering deployed may also
improperly permit spoofing traffic from the connected subnet due to
non-updated or misconfigured ACL, or possible bugs in the
implementation of SAV filtering. As shown in Figure 5, if Router 4
does not strictly implement SAV filtering, spoofing traffic that
leaks out of itself can successfully flow to anywhere in the intra-
domain network without being blocked, because other intra-domain
routers (e.g., Router 6) do not apply SAV for traffic coming from
neighboring routers.
+--------------------------------------------------------------------------+
| +----------+ +----------+ AS |
| | Router 5 <------------+ Router 6 | |
| +----------+ +----------+ |
| / \ /\ Spoofing traffic that leaks|
| / \ \ out of Router 4 |
| \/ \/ +----------+ |
| +----------+ +----------+ | Router 4 | |
| | Router 1 | | Router 2 | +--------#-+ |
| +----------+ +----------+ / /\ |
| \ / \/ | |
| \ / +----------+ Subnet3(p3) |
| \ / | Router 3 | |
| \/ \/ +-----#----+ |
| Subnet1(p1) | |
| \/ |
| Subnet2(p2) |
+--------------------------------------------------------------------------+
If Router 4 accidentally leaks spoofing traffic:
Spoofing traffic from Subnet 3 cannot be blocked by other routers
Figure 5: Negligent edge router.
To increase the resilience of intra-domain SAV to potential
negligence, it is desirable to also apply SAV at other intra-domain
routers to block spoofing traffic as close to the source as possible.
However, existing ingress filtering is not competent to perform
accurate SAV for packets received from a neighboring router. In
particular, strict uRPF can cause traffic interruption in the case of
asymmetric routing.
Li, et al. Expires 25 April 2023 [Page 9]
Internet-Draft Intra-domain SAVNET Problem Statement October 2022
4. Problem Statement
This section summarizes the fundamental problems existing in current
intra-domain SAV from the above gap analysis. The inaccurate
validation, high operational overhead, and limited protection of
current intra-domain SAV mechanisms are three main factors that
hinder the deployment and compromise the effectiveness of intra-
domain SAV.
4.1. Inaccurate Validation
High accuracy, i.e., avoiding improper block problems while trying
best to reduce improper permit problems, is the basic and key problem
of an SAV mechanism. However, ACL-based ingress filtering needs
manual configuration and thus faces limitations in flexibility and
accuracy in dynamic networks. Strict uRPF-based ingress filtering
automatically generates SAV tables, but may improperly block
legitimate traffic under asymmetric routing. The root cause is that
strict uRPF leverages the local FIB table to determine the incoming
interface for source addresses, which may not match the real data-
plane forwarding path from the source, due to the existence of
asymmetric routes. Hence, it may mistakenly consider a valid
incoming interface as invalid, resulting in improper block problems;
or consider an invalid incoming interface as valid, resulting in
improper permit problems.
4.2. High Operational Overhead
Given the problem of inaccurate validation, if network operators want
to apply intra-domain SAV and avoid improper block , they has to
figure out which edge routers have asymmetric routing to the directly
connected subnet, and implement ACL-based SAV at those edge routers
instead of strict uRPF. In addition, they have to manually update
the ACL filtering rules in time when the subnet's prefix or topology
changes. Both identifying asymmetric routes and manual update incur
significant operational overhead for operators.
4.3. Limited Protection
Currently, ingress filtering is applied at edge routers and only
works for traffic from direcly connected subnets, resulting in the
inability to block spoofing traffic from inbound direction.
Therefore, spoofing traffic with even intra-domain source addresses
can easily flow to any subnet from outside the AS, negligent edge
routers, and non-deploying subnets (when intra-domain SAV is
partially deployed).
Li, et al. Expires 25 April 2023 [Page 10]
Internet-Draft Intra-domain SAVNET Problem Statement October 2022
5. Requirements
To make improvements to existing intra-domain SAV mechanisms, a new
intra-domain SAV mechanism MUST satisfy the following requirements.
5.1. Accurate SAV
To determine the accurate incoming interfaces for a specific source
prefix, routers MUST be able to learn the real incoming interfaces
for packets originated from the subnet which owns the source prefix.
In other words, SAV table generation should follow real data-plane
forwarding path information. Since this requirement cannot be met by
using local FIB information, additional mechanisms are needed to
deliver the required information. In this way, the improper block
problem under asymmetric routing can be avoided.
5.2. Acceptable Overhead
The mechanism MUST not induce much overhead. First, it MUST be able
to automatically generate and update the SAV rules instead of relying
entirely on manual configuration. Second, it MUST be applicable to
different routing scenarios, reducing the operation and management
overhead. In the end, it SHOULD avoid data-plane packet modification
and limit the number of control-plane protocol messages.
5.3. All-direction Protection
To provide all-round protection, the new mechanism MUST work for
traffic coming from all directions (i.e. for traffic from both subnet
and neighboring router) and SHOULD be deployed in more routers to
block spoofing traffic (from outside the AS, negligent edge routers,
and non-deploying subnets) as close to the source as possible.
Especially, when partially deployed, it SHOULD be able to limit the
malicious behavior of non-deploying subnets to some extent. At
least, to prevent reflection attacks, it should prevent non-deploying
subnets from forging source addresses of deployed subnets.
6. Intra-domain SAVNET Scope
Intra-domain SAVNET focuses on the same scope corresponding to
existing intra-domain SAV mechanisms. Generally, it includes all IP
encapsulated scenarios:
* Native IP forwarding: including both global routing table
forwarding and CE site forwarding of VPN;
* IP-encapsulation Tunnel (IPsec, GRE, SRv6, etc.): focusing on the
validation of the outer layer IP address;
Li, et al. Expires 25 April 2023 [Page 11]
Internet-Draft Intra-domain SAVNET Problem Statement October 2022
* Both IPv4 and IPv6 addresses
Scope does not include:
* Non-IP encapsulation: including MPLS label-based forwarding and
other non-IP-based forwarding.
7. Security Considerations
Intra-domain SAVNET focuses on routing protocol-based mechanisms. It
aims to use or extend existing routing architecture or protocols to
implement the SAV function. The intra-domain SAVNET mechanism MUST
not introduce additional security vulnerabilities or confusion to the
existing intra-domain control-plane protocols. Similar to the
security scope of intra-domain routing protocols, intra-domain SAVNET
should ensure integrity and authentication of protocol packets that
deliver the required SAV information.
Intra-domain SAVNET does not provide protection against compromised
or misconfigured routers that poison existing control plane
protocols. Such routers can not only disrupt the SAV function, but
also affect the entire routing domain.
8. IANA Considerations
This document does not request any IANA allocations.
9. Normative References
[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>.
[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>.
[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>.
Li, et al. Expires 25 April 2023 [Page 12]
Internet-Draft Intra-domain SAVNET Problem Statement October 2022
Authors' Addresses
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Jianping Wu
Tsinghua University
Beijing
China
Email: jianping@cernet.edu.cn
Lancheng Qin
Tsinghua University
Beijing
China
Email: qlc19@mails.tsinghua.edu.cn
Mingqing Huang
Huawei
Beijing
China
Email: huangmingqing@huawei.com
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Li, et al. Expires 25 April 2023 [Page 13]