Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements
draft-wu-savnet-inter-domain-problem-statement-06
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
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 | Jianping Wu , Dan Li , Libin Liu , Mingqing(Michael) Huang , Nan Geng | ||
| Last updated | 2023-03-04 | ||
| Replaced by | draft-ietf-savnet-inter-domain-problem-statement, draft-ietf-savnet-inter-domain-problem-statement | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Candidate for WG Adoption | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wu-savnet-inter-domain-problem-statement-06
Network Working Group J. Wu
Internet-Draft D. Li
Intended status: Informational Tsinghua University
Expires: 5 September 2023 L. Liu
Zhongguancun Laboratory
M. Huang
N. Geng
Huawei
4 March 2023
Source Address Validation in Inter-domain Networks Gap Analysis, Problem
Statement, and Requirements
draft-wu-savnet-inter-domain-problem-statement-06
Abstract
This document provides the gap analysis of existing inter-domain
source address validation mechanisms, describes the fundamental
problems, and defines the requirements for technical improvements.
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.
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 5 September 2023.
Wu, et al. Expires 5 September 2023 [Page 1]
Internet-Draft Inter-domain SAVNET Problem Statement March 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Existing SAV Mechanisms . . . . . . . . . . . . . . . . . . . 4
4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. SAV at Provider Interface . . . . . . . . . . . . . . . . 6
4.2. SAV at Customer Interface . . . . . . . . . . . . . . . . 8
4.2.1. Limited Propagation of Prefixes . . . . . . . . . . . 8
4.2.2. Hidden Prefixes . . . . . . . . . . . . . . . . . . . 9
4.3. SAV at Peer Interface . . . . . . . . . . . . . . . . . . 11
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 11
6. Requirements for New SAV Mechanisms . . . . . . . . . . . . . 13
6.1. Accurate Validation . . . . . . . . . . . . . . . . . . . 13
6.2. Automatic Update . . . . . . . . . . . . . . . . . . . . 13
6.3. Working in Partial Deployment . . . . . . . . . . . . . . 13
7. Inter-domain SAV Scope . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Source address validation (SAV) protects the network from the source
address spoofing attacks. To be maximally effective, SAV mechanisms
should be applied as close to the source as possible. However, it is
not possible to deploy SAV at all network edges [manrs-antispoofing].
Therefore, a multi-fence architecture called Source Address
Validation Architecture (SAVA) [RFC5210] proposes to implement SAV at
three levels: access network SAV, intra-domain SAV, and inter-domain
SAV. SAVA can help validate source addresses across the whole
Internet and reduce the opportunities and areas of source address
Wu, et al. Expires 5 September 2023 [Page 2]
Internet-Draft Inter-domain SAVNET Problem Statement March 2023
spoofing attacks.
Different operators may choose to deploy different SAV mechanisms at
different levels in the Internet. Besides, given numerous access
networks and ASes managed by different ISPs throughout the world, as
well as routers from various vendors, it is difficult to deploy
access-network SAV across all access networks. Therefore, intra-
domain SAV and inter-domain SAV are necessary to defend against
source address spoofing along the network paths of spoofed packets.
Intra-domain SAV prevents an AS's source addresses from being spoofed
inside or outside of an AS without the help of other ASes, and is
analyzed in [draft-li-savnet-intra-domain-problem-statement]. Inter-
domain SAV prevents an AS's source addresses from being spoofed with
the help of other ASes which the spoofed packets go through.
This document focuses on the analysis of inter-domain SAV. For an AS
deploying inter-domain SAV, the traffic entering the AS and spoofing
other ASes' source addresses will be blocked. As shown in Figure 1,
take AS 1, AS 2, AS 3, and AS 4 as an example to illustrate inter-
domain SAV: P1 is the source prefix of AS 1, and spoofed packets with
source addresses in P1 from AS 4 pass through AS 2 to AS 3. If AS 1
and AS 2 deploy the inter-domain SAV, the spoofed packets can be
blocked at AS 2. Therefore, inter-domain SAV can prevent source
address spoofing as close to the spoofing AS by the collaboration
between ASes.
+------------+
| AS 1(P1) #
+------------+ \
\ Spoofed Packets
+-+#+--------+ with Source Addresses in P1 +------------+
| AS 2 #-----------------------------# AS 4 |
+-+#+--------+ +------------+
/
+------------+ /
| AS 3 #
+------------+
AS 4 sends spoofed packets with source addresses in P1 to AS 3.
If AS 1 and AS 2 deploy inter-domain SAV, the spoofed packets can be blocked at AS 2.
Figure 1: An example for illustrating inter-domain SAV
There are many mechanisms for inter-domain SAV. This document
analyzes the existing inter-domain SAV mechanisms and answers: i)
what are the technical gaps, ii) what are the major problems needing
to be solved, and iii) what are the requirements for further
enhancing inter-domain SAV.
Wu, et al. Expires 5 September 2023 [Page 3]
Internet-Draft Inter-domain SAVNET Problem Statement March 2023
2. Terminology
SAV Rule: The rule that indicates the validity of a specific source
IP address or source IP prefix.
SAV Table: The table or data structure that implements the SAV rules
and is used for source address validation in the dataplane.
Improper Block: The validation results that the packets with
legitimate source addresses are blocked improperly due to inaccurate
SAV rules.
Improper Permit: The validation results that the packets with spoofed
source addresses are permitted improperly due to inaccurate SAV
rules.
3. Existing SAV Mechanisms
This section reviews the existing inter-domain SAV mechanisms using
the ingress filtering [RFC2827] [RFC3704] [manrs-antispoofing],
including ACL-based ingress filtering, loose uRPF, strict uRPF, FP-
uRPF, VRF uRPF, and EFP-uRPF.
* ACL-based Ingress Filtering [RFC2827] [RFC3704]: ACL rules permit
or discard the packets with particular source addresses designated
by manual ACL configurations. This mechanism is commonly deployed
at the customer interfaces of the edge routers connected to the
stub customer ASes or the aggregation routers when ACLs at the
edge are not possible [manrs-antispoofing], which aims to prevent
the customer ASes from spoofing source addresses of other ASes.
Also, it can be deployed at provider interfaces of an AS to block
the obviously disallowed source prefixes, such as prefixes from
the suballocated address space and internal-use only prefixes of
the AS's customer AS [nist-rec]. Besides, the ACL rules need to
be updated in a timely manner to keep consistent with the most
updated filtering criteria by manual configurations.
* Strict uRPF [RFC3704]: This mechanism permits an incoming packet
only if the forwarding information base (FIB) contains a prefix
which encompasses its source address and packet forwarding for
that prefix points to its incoming interface. It is recommended
to deploy at the customer interfaces which directly connected to
customer ASes with suballocated address space [nist-rec].
* Loose uRPF [RFC3704]: This mechanism permits an incoming packet
when the FIB has one or more prefixes which encompass its source
address, and the incoming interface of the packet is not checked.
Loose uRPF can be deployed at any interfaces of the ASes.
Wu, et al. Expires 5 September 2023 [Page 4]
Internet-Draft Inter-domain SAVNET Problem Statement March 2023
Usually, it is recommended to deploy at provider interfaces for
blocking obviously disallowed source prefixes, e.g., non-global
prefixes or the enterprise's own prefixes [nist-rec].
* FP-uRPF [RFC3704]: This mechanism maintains a reverse path
forwarding (RPF) list, which contains the permissible prefixes and
their optimal and alternative routes. It permits an incoming
packet only if the source address is encompassed in the RPF list
and the incoming interface matches any of the optimal or
alternative routes. FP-uRPF is recommended to deploy at the peer
interfaces and customer interfaces, especially for the ones
connected to the multi-homed customers [nist-rec].
* VRF uRPF [RFC4364] [urpf-enhancements]: Virtual routing and
forwarding (VRF) uRPF maintains a dedicated VRF table for each
external BGP peer, which stores the prefixes and their permissible
routes advertised by the external BGP peer. It permits an
incoming packet from an external BGP peer only if the source
address is encompassed in the prefixes of the VRF table for that
peer. Besides, VRF uRPF may be used as BCP38 [RFC2827], but has
not been operaionally proven [manrs-antispoofing].
* EFP-uRPF [RFC8704]: This mechanism improves the flexibility and
accuracy of the uRPF-based methods with two algorithms, i.e.,
Algorithm A and Algorithm B, by following the principle: if BGP
updates for multiple prefixes with the same origin AS were
received on different interfaces (at border routers), then
incoming data packets with source addresses in any of those
prefixes should be accepted on any of those interfaces. The two
algorithms of EFP-uRPF have not been implemented. BCP84 [RFC3704]
[RFC8704] recommends that EFP-uRPF with Algorithm B SHOULD be
applied at the customer interfaces of an AS.
* Source-based remote triggered black hole filtering (RTBH)
[RFC5635]: Source-based RTBH provide the ability to drop traffic
based on a specific source address or ranges of source addresses.
The implementation of source-based RTBH depends on uRPF, most
often loose uRPF. For loose uRPF with source-based RTBH, if there
is not an FIB entry for an incoming packet's source address, or if
the FIB entry points to the black hole (i.e., Null0), the reverse
path forwarding check will fail, and as a result, the packet will
be dropped. Source-based RTBH allows operators to drop the
identified attack traffic at specified devices (e.g., edge router)
of their network based on source addresses.
* Carrier Grade NAT: It has some operations on the source addresses
of packets but is not an antispoofing tool as described in
[manrs-antispoofing]. If the source address of a packet is in the
Wu, et al. Expires 5 September 2023 [Page 5]
Internet-Draft Inter-domain SAVNET Problem Statement March 2023
INSIDE access list, the NAT rule can translate the source address
to an address in the pool OUTSIDE. The NAT rule cannot judge
whether the source address is spoofed or not. Besides, the packet
with a spoofed source address will be forwarded directly if the
spoofed source address is not included in the INSIDE access list.
Therefore, Carrier Grade NAT cannot help block or traceback
spoofed packets, and other SAV mechanisms still need to be
deployed.
* BGP origin validation (BGP-OV) [RFC6811]: An attacker can subvert
any of the uRPF-based methods by performing prefix hijacking
followed by source address spoofing. When the attacker falsely
announces a less-specific prefix, which does not have the
legitimate announcement, existing uRPF-based SAV mechanisms may be
deceived, and the attacker would be able to successfully perform
address spoofing. One way to protect against this type of attack
is to employ the combination of BGP-OV and uRPF-based mechanisms,
e.g., FP-uRPF or EFP-uRPF [nist-rec]. A BGP router can use the
ROA information (i.e., a validated list of {prefix, maxlength,
origin AS}) to mitigate the risk of prefix hijacks in advertised
routes.
4. Gap Analysis
Inter-domain SAV defends against source address spoofing attacks in
different directions of ASes including provider interface, customer
interface, and peer interface. Therefore, in the following, this
section performs gap analysis of existing SAV mechanisms at provider
interface, customer interface, and peer interface to see their
technical limitations.
4.1. SAV at Provider Interface
SAV at provider interface can utilize ACL-based ingress filtering
and/or loose uRPF to prevent spoofing source addresses from provider
AS.
Wu, et al. Expires 5 September 2023 [Page 6]
Internet-Draft Inter-domain SAVNET Problem Statement March 2023
+-----------+
Attacker(P1') +-+ AS 3(P3) |
+---+/\+----+
|
|
| (C2P)
+-----------+
| AS 4(P4) |
+/\+-----+/\+
/ \
/ \
(C2P) / \ (C2P)
+-----------+ +-----------+
Victim+-+ AS 1(P1) | | AS 2(P2) +-+Server
+-----------+ +-----------+
P1' is the spoofed source prefix P1 by the attacker
which is directly or indirectly attached to AS3
Figure 2: A scenario of the reflection attack from provider AS
Figure 2 shows a scenario of the reflection attack from provider AS.
The arrow indicates the direction of the commercial relationship
between two ASes. AS 3 is the provider of AS 4. AS 4 is the
provider of AS 1 and AS 2. Assume AS 4 has deployed inter-domain SAV
and that AS 3 does not. For example, ACL-based ingress filtering can
be deployed at provider interface of AS 4. To avoid improper block
or improper permit problem, network operators must perform timely
update of ACL rules based on the prefix or topology changes of AS 1
and AS 2, in order to be consistent with the real forwarding paths.
Therefore, high operaional overhead will be induced.
Loose uRPF can be deployed at provider interfaces, and it can adapt
to the network changes using the local FIB. Take Figure 2 as an
example. Loose uRPF is enabled at AS 4's provider interface and EFP-
uRPF is deployed at AS 4's customer interfaces. A reflection
attacker may be inside of AS 3 or connected to AS 3 through other
ASes. It sends packets spoofing source addresses of P1 to the server
located in AS 2 to attack the victim in AS 1. Since AS 3 does not
deploy SAV, the malicious packets will arrive at the provider
interfaces of AS 4. However, these attack packets cannot be
successfully blocked by AS 4 with loose uRPF, and thus improper
permit problem arises.
Wu, et al. Expires 5 September 2023 [Page 7]
Internet-Draft Inter-domain SAVNET Problem Statement March 2023
4.2. SAV at Customer Interface
SAV at customer interface can utilize strict uRPF, FP-uRPF, VRF uRPF,
or EFP-uRPF to prevent spoofing source addresses within a customer
cone. However, they may have improper block problems in the two use
cases: limited propagation of prefixes and hidden prefixes.
4.2.1. Limited Propagation of Prefixes
The limited propagation of prefixes would lead to asymmetric routing
and thus result in improper block problems when taking SAV. There
are many factors which can cause limited propagation of prefixes,
such as NO_EXPORT community, NO_ADVERTISE community, and other route
filtering policies. For brevity, we only analyze EFP-uRPF in the
following. The other mechanisms (i.e., strict uRPF, FP-uRPF, and VRF
uRPF) share the same problems.
+-----------------+
| AS 4 |
+-+/\+-------+/\+-+
/ \
/ \
P1[AS 1] / \
/ \
/ (C2P/P2P) (C2P) \
+----------------+ +----------------+
| AS 3 | | AS 2 |
+-------+/\+-----+ +------+/\+------+
\ /
P1[AS 1] \ / P1[AS 1]
\ (C2P) (C2P) / NO_EXPORT
+------------------+
| AS 1 +---P1
+------------------+
Figure 3: Limited propagation of prefixes caused by NO_EXPORT
Wu, et al. Expires 5 September 2023 [Page 8]
Internet-Draft Inter-domain SAVNET Problem Statement March 2023
Figure 3 presents a scenario of limited propagation of prefixes
caused by NO_EXPORT. AS 1 is the common customer of AS 2 and AS 3.
AS 4 is the provider of AS 2. The relationship between AS 3 and AS 4
is customer-to-provider (C2P) or peer-to-peer (P2P). All arrows in
Figure 3 represent BGP advertisements. AS 1 has prefix P1 and
advertises the prefix to the providers, i.e., AS 2 and AS 3. After
receiving the route for prefix P1 from AS 1, AS 3 propagates this
route to AS 4. In contrast, AS 2 does not propagate the route for
prefix P1 to AS 4, since AS 1 adds the NO_EXPORT community attribute
in the BGP advertisement destined to AS 2. Besides, AS 4 deploys
EFP-uRPF at customer interfaces and other ASes do not take SAV. In
this case, AS 4 only learns the route for prefix P1 from AS 3.
Assume that AS 3 is the customer of AS 4. If AS 4 runs EFP-uRPF with
algorithm A at customer interfaces, the packets with source addresses
of P1 are required to arrive only from AS 3. When AS 1 sends the
packets with legitimate source addresses of prefix P1 to AS 4 through
AS 2, AS 4 will improperly block these packets. In addition, strict
uRPF, FP-uRPF, and VRF uRPF also have the improper block problems.
EFP-uRPF with algorithm B works well in this case.
Assume that AS 3 is the peer of AS 4. AS 4 will never learn the
route of P1 from its customer interfaces. So, no matter EFP-uRPF
with algorithm A or that with algorithm B are used by AS 4, there
will be improper block problems.
Again, besides the NO_EXPORT configuration above, there are also many
other route filtering configurations that can result in limited
propagation of prefixes. Improper block may be induced by existing
inter-domain SAV mechanisms when using such configurations, and it is
hard to prevent networks from using these configurations.
4.2.2. Hidden Prefixes
In the case of hidden prefixes, the source addresses of some servers
are not advertised through BGP. This would lead to improper block
problems when using existing inter-domain SAV mechanisms, e.g.,
strict uRPF, FP-uRPF, VRF uRPF, and EFP-uRPF, since they block the
legitimate traffic with unknown prefixes.
Anycast [RFC4786] [RFC7094] is widely used in Content Delivery
Network (CDN) to improve the quality of service by bringing the
content to the user as close as possible. An anycast IP address is
shared by devices in multiple locations, and incoming requests are
routed to the location closest to the sender. In practice, anycast
IP addresses are usually announced only from some locations with
multiple connectivity. Upon receiving incoming requests from users,
the CDN server will create tunnels for the requests to the edge
Wu, et al. Expires 5 September 2023 [Page 9]
Internet-Draft Inter-domain SAVNET Problem Statement March 2023
locations. Subsequently, the edge locations perform direct server
return (DSR), i.e., directly sending the content to the users. To
ensure that DSR works, servers in edge locations must send response
packets with anycast IP address as the source address. However,
since edge locations never advertise the anycast prefixes through
BGP, an intermediate AS with existing inter-domain SAV mechanisms may
improperly block these response packets.
+----------+
Anycast Server+-+ AS 3(P3) |
+--+/\+----+
|
|
| (C2P)
+----------+
| AS 4 |
+/\+----+/\+
/ \
/ \
(C2P) / \ (C2P)
+-----------+ +-----------+
User+-+ AS 1 | | AS 2 +-+Edge Server
+-----------+ +-----------+
P3 is the anycast prefix and is only advertised from AS3
Figure 4: A Direct Server Return (DSR) scenario
Figure 4 shows an example of DSR scenario. The anycast IP prefix
(i.e., P3) is only advertised from AS 3 through BGP. Assume AS 3 is
the provider of AS 4. AS 4 is the provider of AS 1 and AS 2. AS 4
takes SAV at customer interfaces and other ASes do not. When users
in AS 1 send requests to the anycast destination IP, the forwarding
path from users to anycast servers is AS 1 -> AS 4 -> AS 3. Anycast
servers in AS 3 receive the requests and then tunnel them to the edge
servers in AS 2. Finally, the edge servers send the content to the
users with source addresses of prefix P3. The reverse forwarding
path is AS 2 -> AS 4 -> AS 1. Since AS 4 never receives routing
information for prefix P3 from AS 2, EFP-uRPF with algorithm A/B or
other existing uRPF-based mechanisms, e.g., FP-uRPF, VRF uRPF, or
strict uRPF, at AS 4 will improperly block the response packets from
AS 2.
Wu, et al. Expires 5 September 2023 [Page 10]
Internet-Draft Inter-domain SAVNET Problem Statement March 2023
4.3. SAV at Peer Interface
SAV at peer interface can utilize FP-uRPF, VRF uRPF, or EFP-uRPF to
prevent spoofing source addresses from peer AS. And these inter-
domain SAV mechanisms have the same improper block problems as they
take SAV at customer interface in the cases of limited propagation of
prefixes and hidden prefixes.
+-----------+ (P2P) +-----------+
| AS 3(P3) +-------------+ AS 4(P4) |
+-----+-----+ +/\+-----+/\+
| / \
+ / \
Attacker(P1') (C2P) / \ (C2P)
+-----------+ +-----------+
Victim+-+ AS 1(P1) | | AS 2(P2) +-+Server
+-----------+ +-----------+
P1' is the spoofed source prefix P1 by the attacker
which is directly or indirectly attached to AS3
Figure 5: A scenario of the reflection attack from peer AS
Figure 5 shows a scenario of the reflection attack from peer AS. The
arrow indicates the direction of the commercial relationship between
two ASes. AS 3 and AS 4 are peers, and AS 4 is the provider of AS 1
and AS 2. Assume AS 4 has deployed inter-domain SAV and other ASes
do not. EFP-uRPF with algorithm B is deployed at AS 4's peer and
customer interfaces. A reflection attacker may be directly attached
to AS 3 or indirectly attached to AS 3 through other ASes. It sends
packets spoofing source addresses of P1 to the server located in AS 2
for attacking the victim in AS 1. Since AS 3 does not take SAV, the
malicious packets will arrive at the peer interface of AS 4.
However, this attack cannot be successfully blocked by AS 4, since
EFP-uRPF with algorithm B permits prefix P1 on any of AS 4's peer
interfaces.
5. Problem Statement
According to the gap analysis above, existing inter-domain SAV
mechanisms do have improper block or improper permit problems in
asymmetric routing scenarios, and high operaional overhead problem in
dynamic networks.
ACL-based ingress filtering relies on manual configurations of
operators to update ACL rules and adapt to network changes. The ACL
lists need to be updated in a timely manner to be consistent with the
Wu, et al. Expires 5 September 2023 [Page 11]
Internet-Draft Inter-domain SAVNET Problem Statement March 2023
most updated filtering criteria. Otherwise, improper block or
improper permit problems may appear. As a result, high operaional
overhead will be induced to achieve timely updates of ACL rules,
especially for networks with frequent policy and route changes.
Strict uRPF and loose uRPF can generate SAV rules automatically
without manual effort. However, strict uRPF may improperly block
legitimate traffic in asymmetric routing scenarios, while loose uRPF
may improperly permit spoofing traffic. The root cause is that they
both only reply on the local FIB to obtain SAV-related information.
Strict uRPF leverages the local FIB table of routers to learn the
source prefixes and determine their valid incoming interfaces, which
may not match the real data-plane forwarding paths of the source
prefixes, due to the existence of asymmetric routing. Loose uRPF is
a looser version of SAV and only validates the existence of source
prefixes in the local FIB table without checking the incoming
interfaces.
FP-uRPF and VRF uRPF partially solves the improper block problems
identified with the strict uRPF in the multihoming scenarios. They
still have improper block problems in the asymmetric routing
scenarios, e.g., limited propagation of prefixes with NO_EXPORT. The
root cause is that they only rely on the local routing information
base (RIB) to learn the source prefixes and determine the valid
incoming interfaces, which may not match the real data-plane
forwarding paths of the source prefixes.
EFP-uRPF can solve the improper block problems of FP-uRPF and VRF
uRPF in the multihoming scenarios by permiting the prefixes from the
same customer cone at all customer interfaces. However, it may
improperly permit the spoofing traffic from the customer cone.
Besides, improper block problems will be incurred when legitimate
source prefixes are not learned by EFP-uRPF, e.g., DSR. The root
cause is that it cannot learn the real-forwarding paths of the
legitimate source prefixes. As a result, it may mistakenly consider
an invalid incoming interface as valid, resulting in improper permit
problems; or consider a valid incoming interface as invalid,
resulting in improper block problems.
In addition, no one of existing inter-domain SAV mechanisms can be
applied at all the directions of ASes to realize effective SAV in
dynamic or asymmetric routing scenarios. Network operators need to
figure out the network environments accurately to deploy the suitable
SAV mechanisms at the corresponding interfaces with manual
configurations. This also incurs extra operational overhead.
Wu, et al. Expires 5 September 2023 [Page 12]
Internet-Draft Inter-domain SAVNET Problem Statement March 2023
6. Requirements for New SAV Mechanisms
This section lists the requirements for the new SAV mechanisms, which
serve as technical directions for narrowing the technical gaps of
existing inter-domain SAV mechanisms. The requirements are practical
points that can be fully or partially fulfilled by proposing new
techniques.
6.1. Accurate Validation
The new inter-domain SAV mechanisms SHOULD improve the validation
accuracy upon existing mechanisms at all directions of ASes. It
SHOULD avoid the improper block problems and reduce the improper
permit problems of existing inter-domain SAV mechanisms, e.g., loose
uRPF and EFP-uRPF with algorithm B, in the asymmetric routing
scenarios. An AS deploying the new inter-domain SAV mechanisms
SHOULD be able to acquire the real incoming interfaces of the source
prefixes from other ASes which also adopt the new inter-domain SAV
mechanisms.
In other words, accurate validation requires that SAV rules SHOULD
match the real data-plane forwarding paths. Even for the cases where
it is impossible or hard to acquire all the real forwarding paths, it
MUST acquire the mimimal set of acceptable paths which SHOULD cover
the real forwarding ones. This can help avoid improper block and
minimize improper permit. Therefore, the SAV-related information
from multiple sources, such as RPKI ROA objects and ASPA objects and
advertisements of other ASes, can help improve the accuracy.
6.2. Automatic Update
The new inter-domain SAV mechanism MUST be able to adapt to dynamic
networks and asymmetric routing scenarios automatically, instead of
entirely relying on manual update.
6.3. Working in Partial Deployment
The new inter-domain SAV mechanisms MUST provide effective protection
for source addresses even when they partially deployed in the
Internet. Some ASes' routers may not be able to be easily upgraded
for supporting the new SAV mechanisms due to their limitations of
capabilities, versions, or vendors. Thus, it is impractical to
ensure that all the ASes or most of the ASes take SAV simultaneously,
partial deployment or incremental deployment has to be considered for
a new inter-domain SAV mechanism. In particular, the effectiveness
of protection in all directions of ASes under partial deployment
SHOULD NOT be worse than existing uRPF-based SAV mechanisms.
Wu, et al. Expires 5 September 2023 [Page 13]
Internet-Draft Inter-domain SAVNET Problem Statement March 2023
7. Inter-domain SAV Scope
The new inter-domain SAV mechanism should work in the same scenarios
as existing inter-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-encapsulated Tunnel (IPsec, GRE, SRv6, etc.): focusing on the
validation of the outer layer IP address.
* Both IPv4 and IPv6 addresses.
Scope does not include:
* Non-IP packets: including MPLS label-based forwarding and other
non-IP-based forwarding.
In addition, the new inter-domain SAV mechanism should not modify
data-plane packets. Existing architectures or protocols or
mechanisms can be used in the new SAV mechanism to achieve better SAV
function.
8. Security Considerations
SAV rules can be generated based on route information (FIB/RIB) or
non-route information. If the information is poisoned by attackers,
the SAV rules will be false. Lots of legal packets may be dropped
improperly or malicious traffic with spoofed source addresses may be
permitted improperly. Route security should be considered by routing
protocols. Non-route information should also be protected by
corresponding mechanisms or infrastructure. If SAV mechanisms or
protocols require information exchange, there should be some
considerations on the avoidance of message alteration or message
injection.
The SAV procedure referred in this document modifies no field of
packets. So, security considerations on data-plane are not in the
scope of this document.
9. IANA Considerations
This document does not request any IANA allocations.
Wu, et al. Expires 5 September 2023 [Page 14]
Internet-Draft Inter-domain SAVNET Problem Statement March 2023
10. Acknowledgements
Many thanks to Jared Mauch, Barry Greene, Fang Gao, Anthony Somerset,
Kotikalapudi Sriram, Yuanyuan Zhang, Igor Lubashev, Alvaro Retana,
Joel Halpern, Aijun Wang, Michael Richardson, Li Chen, Lancheng Qin,
Gert Doering, Mingxing Liu, John O'Brien, Roland Dobbins, etc. for
their valuable comments on this document.
11. Normative References
[draft-li-savnet-intra-domain-problem-statement]
"Source Address Validation in Intra-domain Networks Gap
Analysis, Problem Statement, and Requirements", 2023,
<https://datatracker.ietf.org/doc/draft-li-savnet-intra-
domain-problem-statement/>.
[manrs-antispoofing]
MANRS, "MANRS Implementation Guide", April 2019,
<https://www.manrs.org/netops/guide/antispoofing/>.
[nist-rec] Sriram, K. and D. Montgomery, "Resilient Interdomain
Traffic Exchange: BGP Security and DDos Mitigation", 2019,
<https://www.nist.gov/publications/resilient-interdomain-
traffic-exchange-bgp-security-and-ddos-mitigation>.
[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>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <https://www.rfc-editor.org/info/rfc4786>.
Wu, et al. Expires 5 September 2023 [Page 15]
Internet-Draft Inter-domain SAVNET Problem Statement March 2023
[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>.
[RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole
Filtering with Unicast Reverse Path Forwarding (uRPF)",
RFC 5635, DOI 10.17487/RFC5635, August 2009,
<https://www.rfc-editor.org/info/rfc5635>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>.
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
"Architectural Considerations of IP Anycast", RFC 7094,
DOI 10.17487/RFC7094, January 2014,
<https://www.rfc-editor.org/info/rfc7094>.
[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>.
[urpf-enhancements]
Cisco Systems, Inc., "Unicast Reverse Path Forwarding
Enhancements for the Internet Service Provider-Internet
Service Provider Network Edge", 2005,
<https://www.cisco.com/c/dam/en_us/about/security/
intelligence/urpf.pdf>.
Authors' Addresses
Jianping Wu
Tsinghua University
Beijing
China
Email: jianping@cernet.edu.cn
Wu, et al. Expires 5 September 2023 [Page 16]
Internet-Draft Inter-domain SAVNET Problem Statement March 2023
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Libin Liu
Zhongguancun Laboratory
Beijing
China
Email: liulb@zgclab.edu.cn
Mingqing Huang
Huawei
Beijing
China
Email: huangmingqing@huawei.com
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Wu, et al. Expires 5 September 2023 [Page 17]