Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements
draft-wu-savnet-inter-domain-problem-statement-08
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 , Kotikalapudi Sriram , Lancheng Qin , Nan Geng | ||
| Last updated | 2023-06-01 (Latest revision 2023-03-25) | ||
| Replaced by | 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-08
Internet Engineering Task Force J. Wu
Internet-Draft D. Li
Intended status: Informational Tsinghua University
Expires: 3 December 2023 L. Liu
Zhongguancun Laboratory
M. Huang
Huawei
K. Sriram
USA NIST
L. Qin
Tsinghua University
N. Geng
Huawei
1 June 2023
Source Address Validation in Inter-domain Networks Gap Analysis, Problem
Statement, and Requirements
draft-wu-savnet-inter-domain-problem-statement-08
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.
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 3 December 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wu, et al. Expires 3 December 2023 [Page 1]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Existing Inter-domain SAV Mechanisms . . . . . . . . . . . . 4
4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. SAV at Provider/Peer Interfaces . . . . . . . . . . . . . 7
4.2. SAV at Customer Interfaces . . . . . . . . . . . . . . . 11
4.2.1. Limited Propagation of Prefixes . . . . . . . . . . . 13
4.2.2. Hidden Prefixes . . . . . . . . . . . . . . . . . . . 14
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 18
6. Requirements for New Inter-domain SAV Mechanisms . . . . . . 20
6.1. Automatic Update . . . . . . . . . . . . . . . . . . . . 20
6.2. Accurate Validation . . . . . . . . . . . . . . . . . . . 20
6.3. Working in Incremental/Partial Deployment . . . . . . . . 21
6.4. Developing a SAV-tailored Protocol . . . . . . . . . . . 21
7. Feasibility Analysis for Satisfying the Requirements . . . . 21
7.1. Integrating Multiple SAV Information Sources . . . . . . 22
7.2. Implementing a SAV-tailored Protocol . . . . . . . . . . 23
8. Inter-domain SAV Scope . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
Source address validation (SAV) is crucial for protecting networks
from source address spoofing attacks. The MANRS initiative advocates
deploying SAV as close to the source as possible [manrs], and access
networks are the first line of defense against source address
spoofing. However, access networks face various challenges in
deploying SAV mechanisms due to different network environments,
router vendors, and operational preferences. Hence, it is not
feasible to deploy SAV at every network edge. Additional SAV
Wu, et al. Expires 3 December 2023 [Page 2]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
mechanisms are needed at other levels of the network to prevent
source address spoofing along the forwarding paths of the spoofed
packets. The Source Address Validation Architecture (SAVA) [RFC5210]
proposes a multi-fence approach that implements SAV at three levels
of the network: access, intra-domain, and inter-domain.
If a spoofing packet is not blocked at the originating access
network, intra-domain and inter-domain SAV mechanisms can help block
the packet along the forwarding path of the packet. As analyzed in
[intra-domain-ps], intra-domain SAV for an AS can prevent a subnet of
the AS from spoofing the addresses of other subnets as well as
prevent incoming traffic to the AS from spoofing the addresses of the
AS, without relying on the collaboration of other ASes. As
complementrary, in scenarios where intra-domain SAV cannot work,
inter-domain SAV leverages the collaboration among ASes to help block
incoming spoofing packets in an AS which spoof the source addresses
of other ASes.
This document provides an analysis of inter-domain SAV. Figure 1
illustrates an example for inter-domain SAV. P1 is the source prefix
of AS 1, and AS 4 sends spoofing packets with P1 as source addresses
to AS 3 through AS 2. Assume AS 4 does not deploy intra-domain SAV,
these spoofing packets cannot be blocked by AS 4. Although AS 1 can
deploy intra-domain SAV to block incoming packets which spoof the
addresses of AS 1, these spoofing traffic from AS 4 to AS 3 do not go
through AS 1, so they cannot be blocked by AS 1. Inter-domain SAV
can help in this scenario. If AS 1 and AS 2 deploy inter-domain SAV,
AS 2 knows the correct incoming interface of packets with P1 as
source addresses, and the spoofing packets can thus be blocked by AS
2 since they come from the incorrect interface.
+------------+
| 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
through AS 2.
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.
Wu, et al. Expires 3 December 2023 [Page 3]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
There are many existing mechanisms for inter-domain SAV. This
document analyzes them and attempts to answer: i) what are the
technical gaps (Section 4), ii) what are the fundamental problems
(Section 5), and iii) what are the practical requirements for the
solution of these problems (Section 6).
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
SAV Rule:
The rule that indicates the validity of a specific source IP
address or source IP prefix.
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.
Real forwading paths:
The paths that the legitimate traffic goes through in the data
plane.
3. Existing Inter-domain SAV Mechanisms
Inter-domain SAV is typically performed at the AS level and can be
deployed at AS border routers (ASBRs) to prevent source address
spoofing. There are various mechanisms available to implement inter-
domain SAV for anti-spoofing ingress filtering [manrs] [isoc], which
are reviewed in this section.
* ACL-based ingress filtering [RFC2827] [RFC3704]: ACL-based ingress
filtering is a technique that relies on ACL rules to filter
packets based on their source addresses. It can be applied at
provider interfaces, peer interfaces, or customer interfaces of an
AS, and is recommended to deploy at provider interfaces or
customer interfaces [manrs] [nist]. At the provider interfaces,
ACL-based ingress filtering can block source prefixes that are
clearly invalid in the inter-domain routing context, such as
Wu, et al. Expires 3 December 2023 [Page 4]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
suballocated or internal-only prefixes of customer ASes [nist].
At the customer interfaces, ACL-based ingress filtering can
prevent customer ASes from spoofing source addresses of other ASes
that are not reachable via the provider AS. It can be implemented
at border routers or aggregation routers if border ACLs are not
feasible [manrs]. However, ACL-based ingress filtering introduces
significant operational overhead, as ACL rules need to be updated
in a timely manner to reflect prefix or routing changes in the
inter-domain routing system, which requires manual configuration
to avoid improper block or improper permit.
* uRPF-based machanisms: A class of SAV mechanisms are based on
Unicast Reverse Path Forwarding (uRPF) [RFC3704]. The core idea
of uRPF for SAV is to exploit the symmetry of inter-domain
routing: in many cases, the best next hop for a destination is
also the best previous hop for the source. In other words, if a
packet arrives from a certain interface, the source address of
that packet should be reachable via the same interface, according
to the FIB. However, symmetry in routing does not always holds in
practice, and to address cases where it does not hold, many
enhancements and modes of uRPF are proposed. Different modes of
uRPF have different levels of strictness and flexibility, and
network operators can choose from them to suit particular network
scenarios. We describe these modes as follows:
- Strict uRPF [RFC3704]: Strict uRPF is the most stringent mode,
and it only permits packets that have a source address that is
covered by a prefix in the FIB, and that the next hop for that
prefix is the same as the incoming interface. This mode is
recommended for deployment at customer interfaces that directly
connect to an AS with suballocated address space, as it can
prevent spoofing attacks from that AS or its downstream ASes
[nist].
- Loose uRPF [RFC3704]: Loose uRPF verifies that the source
address of the packet is routable in the Internet by matching
it with one or more prefixes in the FIB, regardless of which
interface the packet arrives at. If the source address is not
routable, Loose uRPF discards the packet. Loose uRPF is
typically deployed at the provider interfaces of an AS to block
packets with source addresses that are obviously disallowed,
such as non-global prefixes (e.g., private addresses, multicast
addresses, etc.) or the prefixes that belong to the customer AS
itself [nist].
- FP-uRPF [RFC3704]: FP-uRPF maintains a reverse path forwarding
(RPF) list, which contains the prefixes and all their
permissible routes including the optimal and alternative ones.
Wu, et al. Expires 3 December 2023 [Page 5]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
It permits an incoming packet only if the packet's source
address is encompassed in the prefixes of the RPF list and its
incoming interface is included in the permissible routes of the
corresponding prefix. FP-uRPF is recommended to be deployed at
customer interfaces or peer interfaces, especially those that
are connected to multi-homed customer ASes [nist].
- Virtual routing and forwarding (VRF) uRPF [RFC4364] [urpf]: VRF
uRPF uses a separate VRF table for each external BGP peer. A
VRF table is a table that contains the prefixes and the routes
that are advertised by a specific peer. VRF uRPF checks the
source address of an incoming packet from an external BGP peer
against the VRF table for that peer. If the source address
matches one of the prefixes in the VRF table, VRF uRPF allows
the packet to pass. Otherwise, it drops the packet. VRF uRPF
can also be used as a way to implement BCP38 [RFC2827], which
is a set of recommendations to prevent IP spoofing. However,
the operational feasibility of VRF uRPF as BCP38 has not been
proven [manrs].
- EFP-uRPF [RFC8704]: EFP-uRPF consists of two algorithms,
algorithm A and algorithm B. EFP-uRPF is based on the idea
that an AS can receive BGP updates for multiple prefixes that
have the same origin AS at different interfaces. For example,
this can happen when the origin AS is multi-homed and
advertises the same prefixes to different providers. In this
case, EFP-uRPF allows an incoming packet with a source address
in any of those prefixes to pass on any of those interfaces.
This way, EFP-uRPF can handle asymmetric routing scenarios
where the incoming and outgoing interfaces for a packet are
different. EFP-uRPF has not been implemented in practical
networks yet, but BCP84 [RFC3704] [RFC8704] suggests using EFP-
uRPF with algorithm B at customer interfaces of an AS. EFP-
uRPF can also be used at peer interfaces of an AS.
* Source-based remote triggered black hole (RTBH) filtering
[RFC5635]: Source-based RTBH filtering enables the targeted
dropping of traffic by specifying particular source addresses or
address ranges. Source-based RTBH filtering uses uRPF, usually
Loose uRPF, to check the source address of an incoming packet
against the FIB. If the source address of the packet does not
match or is not covered by any prefix in the FIB, or if the route
for that prefix points to a black hole (i.e., Null0), Loose uRPF
discards the packet. This way, source-based RTBH filtering can
filter out attack traffic at specific devices (e.g., ASBR) in an
AS based on source addresses, and improve the security of the
network.
Wu, et al. Expires 3 December 2023 [Page 6]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
* Carrier Grade NAT (CGN): CGN is a network technology used by
service providers to translate between private and public IPv4
addresses within their network. CGN enables service providers to
assign private IPv4 addresses to their customer ASes instead of
public, globally unique IPv4 addresses. The private side of the
CGN faces the customer ASes, and when an incoming packet is
received from a customer AS, CGN checks its source address. If
the source address is included in the address list of the CGN's
private side, CGN performs address translation. Otherwise, it
forwards the packet without translation. However, since CGN
cannot determine whether the source address of an incoming packet
is spoofed or not, additional SAV mechanisms need to be
implemented to prevent source address spoofing [manrs].
* BGP origin validation (BGP-OV) [RFC6811]: Attackers can bypass
uRPF-based SAV mechanisms by using prefix hijacking in combination
with source address spoofing. By announcing a less-specific
prefix that does not have a legitimate announcement, the attacker
can deceive existing uRPF-based SAV mechanisms and successfully
perform address spoofing. To protect against this type of attack,
a combination of BGP-OV and uRPF-based mechanisms like FP-uRPF or
EFP-uRPF is recommended [nist]. BGP routers can use ROA
information, which is a validated list of {prefix, maximum length,
origin AS}, to mitigate the risk of prefix hijacks in advertised
routes.
4. Gap Analysis
Inter-domain SAV is essential in preventing source address spoofing
attacks across all AS interfaces, including those of providers,
peers, and customers. An ideal inter-domain SAV mechanism SHOULD
block all spoofing traffic while permitting legitimate traffic in all
scenarios. However, in some cases, existing SAV mechanisms may
unintentionally block legitimate traffic or permit spoofing traffic.
This section aims to conduct a gap analysis of existing SAV
mechanisms used in the corresponding interfaces of these scenarios to
identify their technical limitations.
4.1. SAV at Provider/Peer Interfaces
SAV is used at provider/peer interfaces to validate traffic entering
the customer cone, including both legitimate and spoofing traffic.
To prevent spoofed source addresses from the provider/peer AS, ACL-
based ingress filtering and/or Loose uRPF can be deployed [nist]. In
addition, source-based RTBH filtering can be used to remotely
configure SAV rules.
Wu, et al. Expires 3 December 2023 [Page 7]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
+--------------------+------------+---------------+
| Scenarios |ACL & S/RTBH| Loose uRPF |
+----------+---------+------------+---------------+
|Legitimate| All | | Normal |
|Traffic |Scenarios| High | |
+----------+---------+Operational +---------------+
|Spoofing | RA | Overhead | |
|Traffic +---------+ |Improper Permit|
| | DA | | |
+----------+---------+------------+---------------+
S/RTBH: Source-based RTBH filtering.
"RA" represents a scenario of the reflection attacks from
provider/peer AS.
"DA" represents a scenario of the direct spoofing attacks from
provider/peer AS.
"Normal" represents the inter-domain SAV mechanism does not cause
improper block for legitimate traffic or improper permit for spoofing
traffic in the corresponding scenarios, and has low operational
overhead.
Figure 2: The gaps of ACL-based ingress filtering, Source-based
RTBH filtering, and Loose uRPF in the corresponding scenarios.
Figure 2 summarizes the gaps of ACL-based ingress filtering, source-
based RTBH filtering, and Loose uRPF for SAV at provider/peer
interfaces in the corresponding scenarios. ACL-based ingress
filtering and source-based RTBH filtering effectively block spoofing
traffic from the reflection attacks or direct spoofing attacks
originating from provider/peer AS, while appropriately allowing
legitimate traffic. However, these methods may come with a high
operational overhead. On the other hand, Loose uRPF correctly
permits legitimate traffic, but it can also mistakenly allow spoofing
traffic to pass through.
In the following, we expose the limitations of ACL-based ingress
filtering, source-based RTBH filtering, and Loose uRPF for SAV at
provider/peer interfaces in scenarios involving the reflection
attacks or direct spoofing atacks.
Wu, et al. Expires 3 December 2023 [Page 8]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
+----------------+
Attacker(P1')+-+ AS 3(P3) |
+-+/\----+/\+----+
/ \
/ \
/ \
/ (C2P/P2P) \
+----------------+ \
| AS 4(P4) | \
++/\+--+/\+--+/\++ \
P6[AS 1, AS 2] / | \ \
P2[AS 2] / | \ \
/ | \ \
/ (C2P) | \ P5[AS 5] \ P5[AS 5]
+----------------+ | \ \
Server+-+ AS 2(P2) | | P1[AS 1] \ \
+----------+/\+--+ | P6[AS 1] \ \
P6[AS 1] \ | NO_EXPORT \ \
P1[AS 1] \ | \ \
NO_EXPORT \ | \ \
\ (C2P) | (C2P) (C2P) \ (C2P) \
+----------------+ +----------------+
Victim+-+ AS 1(P1, P6) | | AS 5(P5) |
+----------------+ +----------------+
P1' is the spoofed source prefix P1 by the attacker which is inside of
AS 3 or connected to AS 3 through other ASes.
Figure 3: A scenario of the reflection attacks from provider/peer AS.
Wu, et al. Expires 3 December 2023 [Page 9]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
+----------------+
Attacker(P2')+-+ AS 3(P3) |
+-+/\----+/\+----+
/ \
/ \
/ \
/ (C2P/P2P) \
+----------------+ \
| AS 4(P4) | \
++/\+--+/\+--+/\++ \
P6[AS 1, AS 2] / | \ \
P2[AS 2] / | \ \
/ | \ \
/ (C2P) | \ P5[AS 5] \ P5[AS 5]
+----------------+ | \ \
| AS 2(P2) | | P1[AS 1] \ \
+----------+/\+--+ | P6[AS 1] \ \
P6[AS 1] \ | NO_EXPORT \ \
P1[AS 1] \ | \ \
NO_EXPORT \ | \ \
\ (C2P) | (C2P) (C2P) \ (C2P) \
+----------------+ +----------------+
Victim+-+ AS 1(P1, P6) | | AS 5(P5) |
+----------------+ +----------------+
P2' is the spoofed source prefix P2 by the attacker which is inside of
AS 3 or connected to AS 3 through other ASes.
Figure 4: A scenario of the direct spoofing attacks from
provider/peer AS.
The scenarios of source address spoofing attacks from the provider/
peer AS are depicted in Figure 3 and Figure 4. In the case of
Figure 3, the attacker spoofs the victim's IP address (P1) and sends
requests to servers' IP address (P2) that respond to such requests.
The servers then send overwhelming responses back to the victim,
exhausting its network resources. Conversely, Figure 4 showcases a
direct spoofing attack, where the attacker spoofs another source
address (P2) and directly targets the victim's IP address (P1),
overwhelming its network resources. The arrows in Figure 3 and
Figure 4 represent the commercial relationships between ASes. AS 3
acts as the provider or lateral peer of AS 4 and the provider for AS
5, while AS 4 serves as the provider for AS 1, AS 2, and AS 5.
Additionally, AS 2 is the provider for AS 1. Suppose AS 1 and AS 4
have deployed inter-domain SAV, while the other ASes have not.
By applying ACL-based ingress filtering at the provider/peer
interface of AS 4, the ACL rules can block any packets with spoofed
source addresses from AS 3 in P1 and P2, effectively preventing
Wu, et al. Expires 3 December 2023 [Page 10]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
reflection or direct spoofing attacks. However, this approach incurs
heavy operational overhead, as it requires network operators to
update the ACL rules promptly based on changes in prefixes or
topology of AS 1 and AS 2. Otherwise, it may cause improper block or
improper permit of legitimate traffic.
Source-based RTBH filtering allows for the deployment of SAV rules on
AS 1 and AS 4 remotely. However, in order to avoid improper block or
improper permit, the specified source addresses need to be updated in
a timely manner, which incurs additional operational overhead.
Loose uRPF can greatly reduce the operational overhead because it
uses the local FIB as information source, and can adapt to changes in
the network. However, it can improperly permit spoofed packets. In
Figure 3 and Figure 4, Loose uRPF is enabled at AS 4's provider/peer
interface, while EFP-uRPF is enabled at AS 4's customer interfaces,
following [RFC3704]. An attacker inside AS 3 or connected to it
through other ASes may send packets with source addresses spoofing P1
to a server in AS 2 to attack the victim in AS 1 or send packets with
source addresses spoofing P2 and destimation addresses in P1 to
directly attack the victim in AS 1. As AS 3 lacks deployment of
inter-domain SAV, the attack packets will reach AS 4's provider/peer
interface. With Loose uRPF, AS 4 cannot block the attack packets at
its provider/peer interface, and thus resulting in improper permit.
4.2. SAV at Customer Interfaces
To prevent the spoofing of source addresses within a customer cone,
operators can enable ACL-based ingress filtering, source-based RTBH
filtering, and/or uRPF-based mechanisms at the customer interface,
namely Strict uRPF, FP-uRPF, VRF uRPF, or EFP-uRPF. However, ACL-
based ingress filtering and source-based RTBH filtering need to
update SAV rules in a timely manner and have the same operational
overhead as performing SAV at provider/peer interfaces, while uRPF-
based mechanisms may cause improper block problems in two inter-
domain scenarios: limited propagation of prefixes and hidden
prefixes. In the following, we show how uRPF-based mechanisms may
block legitimate traffic or permit spoofing traffic in the
corresponding scenarios.
Wu, et al. Expires 3 December 2023 [Page 11]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
+------------------+------------+-----------+-------+--------+--------+
| Scenarios |ACL & S/RTBH|Strict uRPF|FP-uRPF|VRF uRPF|EFP-uRPF|
+----------+-------+------------+-----------+-------+--------+--------+
|Legitimate| LPP | | |
|Traffic +-------+ | Improper Block |
| | HP | High | |
+----------+-------+Operational +----------------------------+--------+
|Spoofing | RA | Overhead | |Improper|
|Traffic +-------+ | Normal |Permit |
| | DA | | | |
+----------+-------+------------+----------------------------+--------+
S/RTBH: Source-based RTBH filtering.
"LPP" represents a scenario of limited propagation of prefixes.
"HP" represents a scenario of hidden prefixes.
"RA" represents a scenario of the reflection attacks within
a customer cone.
"DA" represents a scenario of the direct spoofing attacks within
a customer cone.
"Normal" represents the inter-domain SAV mechanism does not cause
improper block for legitimate traffic or improper permit for spoofing
traffic in the corresponding scenarios, and has low operational
overhead.
Figure 5: The gaps of ACL-based ingress filtering, Source-based
RTBH filtering, Strict uRPF, FP-uRPF, VRF uRPF, and EFP-uRPF in
the corrresponding scenarios.
Figure 5 provides an overview of the gaps associated with ACL-based
ingress filtering, source-based RTBH filtering, Strict uRPF, FP-uRPF,
VRF uRPF, and EFP-uRPF for SAV at customer interfaces in the
corresponding scenarios. Both ACL-based ingress filtering and
source-based RTBH filtering have high operational overhead as
performing SAV at provider/peer interfaces. Strict uRPF, FP-uRPF,
VRF uRPF, and EFP-uRPF, on the other hand, may incorrectly block
legitimate traffic in the scenarios of limited propagation of
prefixes or hidden prefixes. Furthermore, in scenarios involving
reflection or direct spoofing attacks, EFP-uRPF may inadvertently
permit spoofing traffic.
In the following, we illustrate the limitations of Strict uRPF, FP-
uRPF, VRF uRPF, and EFP-uRPF for SAV at customer interfaces in
scenarios of limited propagation of prefixes or hidden prefixes.
Wu, et al. Expires 3 December 2023 [Page 12]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
4.2.1. Limited Propagation of Prefixes
In inter-domain networks, some prefixes may not be propagated to all
domains due to various factors, such as NO_EXPORT or NO_ADVERTISE
communities or other route filtering policies. This may cause
asymmetric routing in the inter-domain context, which may lead to
false positives when performing SAV with existing mechanisms. These
mechanisms include EFP-uRPF, which we focus on in the following
analysis, as well as Strict uRPF, FP-uRPF, and VRF uRPF. All these
mechanisms suffer from the same problem of improper block in this
scenario.
+----------------+
| AS 3(P3) |
+-+/\----+/\+----+
/ \
/ \
/ \
/ (C2P) \
+----------------+ \
| AS 4(P4) | \
++/\+--+/\+--+/\++ \
P6[AS 1, AS 2] / | \ \
P2[AS 2] / | \ \
/ | \ \
/ (C2P) | \ P5[AS 5] \ P5[AS 5]
+----------------+ | \ \
| AS 2(P2) | | P1[AS 1] \ \
+----------+/\+--+ | P6[AS 1] \ \
P6[AS 1] \ | NO_EXPORT \ \
P1[AS 1] \ | \ \
NO_EXPORT \ | \ \
\ (C2P) | (C2P/P2P)(C2P) \ (C2P) \
+----------------+ +----------------+
| AS 1(P1, P6) | | AS 5(P5) |
+----------------+ +----------------+
Figure 6: Limited propagation of prefixes caused by NO_EXPORT.
Figure 6 presents a scenario where the limited propagation of
prefixes occurs due to the NO_EXPORT community attribute. In this
scenario, AS 1 is a customer of AS 2, AS 2 is a customer of AS 4, AS
4 is a customer of AS 3, and AS 5 is a customer of both AS 3 and AS
4. The relationship between AS 1 and AS 4 can be either customer-to-
provider (C2P) or peer-to-peer (P2P). AS 1 advertises prefixes P1
and P6 to AS 2, while AS 2 propagates P6 to AS 4. AS 1 adds the
NO_EXPORT community attribute to the BGP advertisement sent to AS 2,
preventing AS 2 from further propagating the route for prefix P1 to
Wu, et al. Expires 3 December 2023 [Page 13]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
AS 4. Similarly, AS 1 adds the NO_EXPORT community attribute to the
BGP advertisement sent to AS 4, resulting in AS 4 not propagating the
route for prefix P6 to AS 3. Consequently, AS 4 only learns the
route for prefix P1 from AS 1 in this scenario. Suppose AS 1 and AS
4 have deployed inter-domain SAV while other ASes have not, and AS 4
has deployed EFP-uRPF at its customer interfaces.
Assuming that AS 1 is the customer of AS 4, if AS 4 deploys EFP-uRPF
with algorithm A at customer interfaces, it will require packets with
source addresses in P1 to only arrive from AS 1. When AS 1 sends
legitimate packets with source addresses in P1 to AS 4 through AS 2,
AS 4 improperly blocks these packets. The same problem applies to
Strict uRPF, FP-uRPF, and VRF uRPF. Although EFP-uRPF with algorithm
B can avoid improper block in this case, network operators need to
first determine whether limited prefix propagation exists before
choosing the suitable EFP-uRPF algorithms, which adds more complexity
and overhead to network operators. Furthermore, EFP-uRPF with
algorithm B is not without its problems. For example, if AS 1 is the
peer of AS 4, AS 4 will not learn the route of P1 from its customer
interfaces. In such case, both EFP-uRPF with algorithm A and
algorithm B have improper block problems.
4.2.2. Hidden Prefixes
Some servers' source addresses are not advertised through BGP to
other ASes. These addresses are unknown to the inter-domain routing
system and are called hidden prefixes. Legitimate traffic with these
hidden prefixes may be dropped by existing inter-domain SAV
mechanisms, such as Strict uRPF, FP-uRPF, VRF uRPF, or EFP-uRPF,
because they do not match any known prefix.
For example, Content Delivery Networks (CDN) use anycast [RFC4786]
[RFC7094] to improve the quality of service by bringing content
closer to users. An anycast IP address is assigned to devices in
different locations, and incoming requests are routed to the closest
location. Usually, only locations with multiple connectivity
announce the anycast IP address through BGP. The CDN server receives
requests from users and creates tunnels to the edge locations, where
content is sent directly to users using direct server return (DSR).
DSR requires servers in the edge locations to use the anycast IP
address as the source address in response packets. However, these
edge locations do not announce the anycast prefixes through BGP, so
an intermediate AS with existing inter-domain SAV mechanisms may
improperly block these response packets.
Wu, et al. Expires 3 December 2023 [Page 14]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
+----------------+
Anycast Server+-+ AS 3(P3) |
+-+/\----+/\+----+
/ \
P3[AS 3] / \ P3[AS 3]
/ \
/ (C2P) \
+----------------+ \
| AS 4(P4) | \
++/\+--+/\+--+/\++ \
P6[AS 1, AS 2] / | \ \
P2[AS 2] / | \ \
/ | \ \
/ (C2P) | \ P5[AS 5] \ P5[AS 5]
+----------------+ | \ \
User+-+ AS 2(P2) | | P1[AS 1] \ \
+----------+/\+--+ | P6[AS 1] \ \
P6[AS 1] \ | NO_EXPORT \ \
P1[AS 1] \ | \ \
NO_EXPORT \ | \ \
\ (C2P) | (C2P) (C2P) \ (C2P) \
+----------------+ +----------------+
Edge Server+-+ AS 1(P1, P6) | | AS 5(P5) |
+----------------+ +----------------+
P3 is the anycast prefix and is only advertised by AS 3 through BGP.
Figure 7: A Direct Server Return (DSR) scenario.
Figure 7 illustrates a DSR scenario where the anycast IP prefix P3 is
only advertised by AS 3 through BGP. In this example, AS 3 is the
provider of AS 4 and AS 5, AS 4 is the provider of AS 1, AS 2, and AS
5, and AS 2 is the provider of AS 1. AS 1 and AS 4 have deployed
inter-domain SAV, while other ASes have not. When users in AS 2 send
requests to the anycast destination IP, the forwarding path is AS
2->AS 4->AS 3. The anycast servers in AS 3 receive the requests and
tunnel them to the edge servers in AS 1. Finally, the edge servers
send the content to the users with source addresses in prefix P3.
The reverse forwarding path is AS 1->AS 4->AS 2. Since AS 4 does not
receive routing information for prefix P3 from AS 1, EFP-uRPF with
algorithm A/B, and all other existing uRPF-based mechanisms at the
customer interface of AS 4 facing AS 1 will improperly block the
legitimate response packets from AS 1.
Moreover, it is worth mentioning that EFP-uRPF with algorithm A/B may
also permit spoofing traffic improperly in scenarios where reflection
or direct spoofing attacks occur. We provide illustrations of these
scenarios below.
Wu, et al. Expires 3 December 2023 [Page 15]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
+----------------+
| AS 3(P3) |
+-+/\----+/\+----+
/ \
/ \
/ \
/ (C2P) \
+----------------+ \
| AS 4(P4) | \
++/\+--+/\+--+/\++ \
P6[AS 1, AS 2] / | \ \
P2[AS 2] / | \ \
/ | \ \
/ (C2P) | \ P5[AS 5] \ P5[AS 5]
+----------------+ | \ \
Attacker(P1')-+ AS 2(P2) | | P1[AS 1] \ \
+----------+/\+--+ | P6[AS 1] \ \
P6[AS 1] \ | NO_EXPORT \ \
P1[AS 1] \ | \ \
NO_EXPORT \ | \ \
\ (C2P) | (C2P) (C2P) \ (C2P) \
+----------------+ +----------------+
Victim+-+ AS 1(P1, P6) | Server+-+ AS 5(P5) |
+----------------+ +----------------+
P1' is the spoofed source prefix P1 by the attacker which is inside of
AS 2 or connected to AS 2 through other ASes.
Figure 8: A scenario of the reflection attacks within a customer
cone.
Wu, et al. Expires 3 December 2023 [Page 16]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
+----------------+
| AS 3(P3) |
+-+/\----+/\+----+
/ \
/ \
/ \
/ (C2P) \
+----------------+ \
| AS 4(P4) | \
++/\+--+/\+--+/\++ \
P6[AS 1, AS 2] / | \ \
P2[AS 2] / | \ \
/ | \ \
/ (C2P) | \ P5[AS 5] \ P5[AS 5]
+----------------+ | \ \
Attacker(P5')-+ AS 2(P2) | | P1[AS 1] \ \
+----------+/\+--+ | P6[AS 1] \ \
P6[AS 1] \ | NO_EXPORT \ \
P1[AS 1] \ | \ \
NO_EXPORT \ | \ \
\ (C2P) | (C2P) (C2P) \ (C2P) \
+----------------+ +----------------+
Victim+-+ AS 1(P1, P6) | | AS 5(P5) |
+----------------+ +----------------+
P5' is the spoofed source prefix P5 by the attacker which is inside of
AS 2 or connected to AS 2 through other ASes.
Figure 9: A scenario of the direct spoofing attacks within a
customer cone.
The scenarios depicted in Figure 8 and Figure 9 involve spoofing
attacks occurring within a customer cone. In Figure 8, the attack
takes place within AS 4's customer cone, where the attacker spoofs
the victim's IP address (P1) and sends requests to servers' IP
address (P5) that are designed to respond to such requests. As a
result, the server sends overwhelming responses back to the victim,
thereby exhausting its network resources. On the other hand,
Figure 9 portrays a direct spoofing attack, where the attacker spoofs
a different source address (P5) and directly targets the victim's IP
address (P1), overwhelming its network resources. The arrows in both
Figure 8 and Figure 9 illustrate the commercial relationships between
ASes. AS 3 serves as the provider for AS 4 and AS 5, while AS 4 acts
as the provider for AS 1, AS 2, and AS 5. Additionally, AS 2 is the
provider for AS 1. Suppose AS 1 and AS 4 have deployed inter-domain
SAV, while the other ASes have not.
Wu, et al. Expires 3 December 2023 [Page 17]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
If AS 4 deploys EFP-uRPF with algorithm A/B at its customer
interfaces, it will allow packets with source addresses in P1 or P5
to originate from AS 1, AS 2, and AS 5. Consequently, when AS 2
sends spoofing packets with source addresses in P1 or P5 to AS 4, AS
4 will improperly permit these packets, thus enabling the spoofing
attacks to propagate.
In scenarios like these, Strict uRPF, FP-uRPF, and VRF uRPF do not
suffer from improper permit problems. This is because these
mechanisms enforce strict filtering rules that ensure packets with
source addresses in P1 are only allowed to arrive from AS 1, and
packets with source addresses in P5 are only permitted to arrive from
AS 5.
5. Problem Statement
+--------+------------+-----------+----------+-------+--------+--------+
|Problems|ACL & S/RTBH|Strict uRPF|Loose uRPF|FP-uRPF|VRF uRPF|EFP-uRPF|
+--------+------------+-----------+----------+-------+--------+--------+
|Improper| - | LPP, | - | LPP, | LPP, | LPP, |
|Block | - | HP | | HP | HP | HP |
+--------+------------+-----------+----------+-------+--------+--------+
|Improper| - | - | DAP, | - | - | DAC, |
|Permit | | | RAP | | - | RAC |
+--------+------------+-----------+----------+-------+--------+--------+
| | Dynamic | | | | | |
| HOO | Networks | - | - | - | - | - |
| | | | | | | |
+--------+------------+-----------+----------+-------+--------+--------+
S/RTBH: Source-based RTBH filtering, HOO: High Operational Overhead.
"LPP" represents a scenario of limited propagation of prefixes.
"HP" represents a scenario of hidden prefixes.
"RAP" represents a scenario of the reflection attacks from
provider/peer AS.
"DAP" represents a scenario of the direct spoofing attacks from
provider/peer AS.
"RAC" represents a scenario of the reflection attacks within
a customer cone.
"DAC" represents a scenario of the direct spoofing attacks within
a customer cone.
"Dynamic Networks" represents the networks that may have frequent
topology changes, route changes, or prefix changes.
"-" represents that the inter-domain SAV mechanism does not have
the corresponding problem.
Wu, et al. Expires 3 December 2023 [Page 18]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
Figure 10: The scenarios where existing inter-domain SAV
mechanisms may have improper block for legitimate traffic,
improper permit for spoofing traffic, or high operational
overhead.
Based on the analysis above, we conclude that existing inter-domain
SAV mechanisms exhibit limitations in asymmetric routing scenarios,
leading to potential issues of improper block or improper permit.
Additionally, these mechanisms can result in high operational
overhead, especially when network routing undergoes dynamic changes.
Figure 10 provides a comprehensive summary of scenarios where
existing inter-domain SAV mechanisms may encounter issues, including
instances of improper blocking of legitimate traffic, improper
permitting of spoofing traffic, or high operational overhead.
For ACL-based ingress filtering, network operators need to manually
update ACL rules to adapt to network changes. Otherwise, they may
cause improper block or improper permit issues. Manual updates
induce high operational overhead, especially in networks with
frequent policy and route changes. Source-based RTBH filtering has
the similar problem as ACL-based ingress filtering.
Strict uRPF and Loose uRPF are automatic SAV mechanisms, thus they do
not need any manual effort to adapt to network changes. However,
they have issues in scenarios with asymmetric routing. Strict uRPF
may cause improper block problems when an AS is multi-homed and
routes are not symmetrically announced to all its providers. This is
because the local FIB may not include the asymmetric routes of the
legitimate packets, and Strict uRPF only uses the local FIB to check
the source addresses and incoming interfaces of packets. Loose uRPF
may cause improper permit problems and fail to prevent source address
spoofing. This is because it is oblivious to the incoming interfaces
of packets.
FP-uRPF and VRF uRPF improve Strict uRPF in multi-homing scenarios.
However, they still have improper block issues in asymmetric routing
scenarios. For example, they may not handle the cases of limited
propagation of prefixes. These mechanisms use the local RIB to learn
the source prefixes and their valid incoming interfaces. But the RIB
may not have all the prefixes with limited propagation and their
permissible incoming interfaces.
Wu, et al. Expires 3 December 2023 [Page 19]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
EFP-uRPF allows the prefixes from the same customer cone at all
customer interfaces. This solves the improper block problems of FP-
uRPF and VRF uRPF in multi-homing scenarios. However, this approach
also compromises partial protection against spoofing from the
customer cone. EFP-uRPF may still have improper block problems when
it does not learn legitimate source prefixes. For example, hidden
prefixes are not learned by EFP-uRPF.
Finally, existing inter-domain SAV mechanisms cannot work in all
directions (i.e. interfaces) of ASes to achieve effective SAV.
Network operators need to carefully analyze the network environment
and choose approapriate SAV mechansim for each interface. This leads
to additional operational and cognitive overhead, which can hinder
the rate of adoption of inter-domain SAV.
6. Requirements for New Inter-domain SAV Mechanisms
This section lists the requirements which can help bridge the
technical gaps of existing inter-domain SAV mechanisms. These
requirements serve as practical guidelines that can be met, in part
or in full, by proposing new techniques.
6.1. Automatic Update
The new inter-domain SAV mechanism MUST be able to adapt to dynamic
networks and asymmetric routing scenarios automatically, instead of
relying on manual update.
6.2. Accurate Validation
The new inter-domain SAV mechanism SHOULD improve the validation
accuracy in all directions of ASes over existing inter-domain SAV
mechanisms. It SHOULD avoid improper block and minimize improper
permit so that the legitimate traffic from an AS will not be blocked
and the spoofed traffic will be reduced as much as possible. To
avoid improper block, ASes that deploy the new inter-domain SAV
mechanism SHOULD be able to acquire all the real data-plane
forwarding paths, which the paths that the legitimate traffic goes
through in the data plane.
However, it may be hard to learn the real forwarding paths of
prefixes exactly under some scenarios, such as asymmetric routing and
DSR. For such scenarios, it is essential to obtain a minimal set of
acceptable paths that cover the real forwarding paths to avoid
improper block and minimize improper permit. Note that the
acceptable paths are all the possible paths that the legitimate
traffic may go through in the data plane, cover all the links at each
level of customer-provider hierarchy, and MUST include all the real
Wu, et al. Expires 3 December 2023 [Page 20]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
forwarding paths. Reducing the set of acceptable paths means
eliminating the paths that are not the real forwarding paths of the
prefixes from the set.
6.3. Working in Incremental/Partial Deployment
The new inter-domain SAV mechanism SHOULD NOT assume pervasive
adoption and SHOULD provide effective protection for source addresses
when it is partially deployed in the Internet. Not all AS border
routers can support the new SAV mechanism at once, due to various
constraints such as capabilities, versions, or vendors. The new SAV
mechanism should not be less effective in protecting all directions
of ASes under partial deployment than existing mechanisms.
6.4. Developing a SAV-tailored Protocol
In order to learn the real forwarding paths of prefixes from ASes, a
unified SAV-tailored protocol SHOULD be developed by the new inter-
domain SAV mechanism for exchanging the SAV-related information such
as prefixes, their incoming interfaces, and topological information
of ASes. The unified SAV-tailored protocol will define the specific
information to be communicated, the communication format, and the
operations for originating, processing, propagating, and terminating
the messages which carry the predefined information.
The need for a unified SAV-tailored protocol arises from the fact
that different ASes are managed by different network operators, who
require a mutually recognized and supported protocol to send their
own source prefixes that need to be protected by other ASes.
Additionally, based on the protocol, an AS can receive, propagate,
and process the messages carrying the source prefixes from other
ASes.
Moreover, the unified SAV-tailored protocol SHOULD perform security
authentication to secure the communicated information and prevent
malicious ASes from generating incorrect or forged information. The
protocol SHOULD also be scalable independently from the growth of the
deployed ASes.
7. Feasibility Analysis for Satisfying the Requirements
This section conducts a feasibility analysis of meeting the
requirements by proposing new techniques. As analyzed in
Section 6.2, learning a minimal set of acceptable paths that cover
the real forwarding paths of prefixes can avoid improper block and
minimize improper permit, particularly when the real forwarding paths
cannot be accurately learned. Multiple sources of SAV-related
information, such as RPKI ROA objects, ASPA objects, and SAV-tailored
Wu, et al. Expires 3 December 2023 [Page 21]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
information from other ASes, can assist in reducing the set of
acceptable paths. Furthermore, when an AS desires other ASes to
assist in protecting its prefixes, it SHOULD inform other ASes of its
prefixes with a SAV-tailored protocol and collaborate with them in
creating SAV rules. The SAV-tailored protocol can be implemented
based on multiprotocol extentions for BGP [RFC4760].
7.1. Integrating Multiple SAV Information Sources
+----------------+
| AS 3(P3) |
+-+/\----+/\+----+
/ \
/ \
/ \
/ (C2P) \
+----------------+ \
| AS 4(P4) | \
++/\+--+/\+--+/\++ \
P6[AS 1, AS 2] / | \ \
P2[AS 2] / | \ \
/ | \ \
/ (C2P) | \ P5[AS 5] \ P5[AS 5]
+----------------+ | \ \
| AS 2(P2) | | P1[AS 1] \ \
+----------+/\+--+ | P6[AS 1] \ \
P6[AS 1] \ | NO_EXPORT \ \
P1[AS 1] \ | \ \
NO_EXPORT \ | \ \
\ (C2P) | (C2P) (C2P) \ (C2P) \
+----------------+ +----------------+
| AS 1(P1, P6) | | AS 5(P5) |
+----------------+ +----------------+
Figure 11: An example to illustrate accurate validation in all
directions of an AS.
Figure 11 is used as an example to illustrate how to avoid improper
block and minimize improper permit in all directions of an AS based
on different SAV information sources. AS 3 is the provider of AS 4
and AS 5, while AS 4 is the provider of AS 1, AS 2, and AS 5, and AS
2 is the provider of AS 1. Assuming prefixes P1, P2, P3, P4, P5, and
P6 are all the prefixes in the network. Inter-domain SAV has been
deployed by AS 1 and AS 4, but not by other ASes. Here, the focus is
on how to conduct SAV in all directions of AS 4 when different SAV
information sources are used. Note that since the source prefix
ranges of the traffic from outside the customer cone of AS 4 are not
fully learned in the partial deployment scenario, SAV at the
Wu, et al. Expires 3 December 2023 [Page 22]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
provider/peer interfaces for traffic from outside the customer cone
can use a block list. For example, as shown in Figure 11, the
traffic with source addresses in P5 may come from AS 5 or AS 3. In
contrast, SAV at the customer interfaces for traffic from inside the
customer cone can use a permit list to allow the known prefixes of
the customer cone at the corresponding customer interfaces and other
unknown prefixes at all the customer interfaces. The followings show
how to generate SAV rules based on the SAV-related information from
different SAV information sources to avoid improper block and reduce
as much improper permit as possible.
* If only the RIB is available, AS 4 can conduct SAV towards its
neighboring ASes as follows: SAV towards AS 1 permits the prefixes
P1 and P6, SAV towards AS 2 permits the prefixes P1, P2, and P6,
SAV towards AS 5 permits the prefix P5, and SAV towards AS 3 does
not block any prefix.
* When both RPKI ROA and ASPA are deployed by AS 1 and AS 4, AS 4
can conduct SAV towards its neighboring ASes as follows: SAV
towards AS 1 permits the prefixes P1 and P6, SAV towards AS 2
permits the prefixes P1, P2, and P6, SAV towards AS 5 permits the
prefix P5, and SAV towards AS 3 blocks the prefixes P1, P2, and
P6.
* Moreover, if SAV-tailored information that contains real data-
plane forwarding paths of prefixes is accessible, SAV rules can be
refined based on more accurate information. AS 4 can conduct SAV
towards its neighboring ASes as follows: SAV towards AS 1 permits
only P1. SAV towards AS 2 permits the prefixes P2 and P6, while
SAV towards AS 5 permits the prefix P5 and SAV towards AS 3 blocks
the prefixes P1, P2, and P6.
It is evident that, in a partial deployment scenario, more accurate
SAV-related information can effectively achieve 0% improper block and
significantly minimize improper permit.
7.2. Implementing a SAV-tailored Protocol
The SAV-tailored protocol serves as a means of exchanging SAV-
tailored information, such as prefixes, between ASes, and can be
implemented by extending the BGP [RFC4760]. To distinguish the SAV-
tailored protocol, a new Address Family Identifier (AFI) and
subsequent Address Family Identifier (SAFI) can be defined, and the
relevant information for SAV can be encapsulated within Multiprotocol
Reachable NLRI.
Wu, et al. Expires 3 December 2023 [Page 23]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
However, it is important to note that the processing and
communication of SAV-tailored information with extensions for BGP may
impose significant overhead. As an alternative approach, the SAV-
tailored protocol can be implemented as a dedicated data-plane
protocol, separate from the control plane. This design choice helps
mitigate processing overhead by offloading it to the data plane,
ensuring more efficient operation.
8. 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: This includes both global routing table
forwarding and CE site forwarding of VPN.
* IP-encapsulated Tunnel (IPsec, GRE, SRv6, etc.): In this scenario,
we focus on the validation of the outer layer IP address.
* Both IPv4 and IPv6 addresses.
Scope does not include:
* Non-IP packets: This includes 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 inherited by the new SAV mechanism to achieve
better SAV effectiveness.
9. 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. Legitimate 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, such as ASPA, 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.
Wu, et al. Expires 3 December 2023 [Page 24]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
10. IANA Considerations
This document does not request any IANA allocations.
11. References
11.1. Normative References
[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/rfc/rfc8174>.
[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/rfc/rfc2119>.
[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/rfc/rfc3704>.
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/rfc/rfc8704>.
[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/rfc/rfc2827>.
[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/rfc/rfc5210>.
[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/rfc/rfc4364>.
[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/rfc/rfc5635>.
Wu, et al. Expires 3 December 2023 [Page 25]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
[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/rfc/rfc6811>.
[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/rfc/rfc4786>.
[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/rfc/rfc7094>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/rfc/rfc4760>.
11.2. Informative References
[intra-domain-ps]
"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] MANRS, "MANRS Implementation Guide", 2023,
<https://www.manrs.org/netops/guide/antispoofing/>.
[isoc] Internet Society, "Addressing the challenge of IP
spoofing", 2015,
<https://www.internetsociety.org/resources/doc/2015/
addressing-the-challenge-of-ip-spoofing/>.
[nist] NIST, "Resilient Interdomain Traffic Exchange: BGP
Security and DDos Mitigation", 2019,
<https://www.nist.gov/publications/resilient-interdomain-
traffic-exchange-bgp-security-and-ddos-mitigation>.
[urpf] 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>.
Wu, et al. Expires 3 December 2023 [Page 26]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
Acknowledgements
Many thanks to Jared Mauch, Barry Greene, Fang Gao, Anthony Somerset,
Yuanyuan Zhang, Igor Lubashev, Alvaro Retana, Joel Halpern, Aijun
Wang, Michael Richardson, Li Chen, Gert Doering, Mingxing Liu, John
O'Brien, Roland Dobbins, etc. for their valuable comments on this
document.
Authors' Addresses
Jianping Wu
Tsinghua University
Beijing
China
Email: jianping@cernet.edu.cn
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
Kotikalapudi Sriram
USA National Institute of Standards and Technology
Gaithersburg, MD
United States of America
Email: ksriram@nist.gov
Wu, et al. Expires 3 December 2023 [Page 27]
Internet-Draft Inter-domain SAVNET Problem Statement June 2023
Lancheng Qin
Tsinghua University
Beijing
China
Email: qlc19@mails.tsinghua.edu.cn
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Wu, et al. Expires 3 December 2023 [Page 28]