| Internet-Draft | Inter-domain SAVNET Problem Statement | June 2023 |
| Wu, et al. | Expires 3 December 2023 | [Page] |
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.¶
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 (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.¶
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 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.
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).¶
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.¶
The rule that indicates the validity of a specific source IP address or source IP prefix.¶
The validation results that the packets with legitimate source addresses are blocked improperly due to inaccurate SAV rules.¶
The validation results that the packets with spoofed source addresses are permitted improperly due to inaccurate SAV rules.¶
The paths that the legitimate traffic goes through in the data plane.¶
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.¶
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:¶
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.¶
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.¶
+--------------------+------------+---------------+ | 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 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.¶
+----------------+
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.
+----------------+
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.
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 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.¶
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.¶
+------------------+------------+-----------+-------+--------+--------+ | 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 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.¶
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 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 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.¶
+--------+------------+-----------+----------+-------+--------+--------+ |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.
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.¶
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.¶
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.¶
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.¶
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 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.¶
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.¶
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.¶
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 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].¶
+----------------+
| 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 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 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.¶
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.¶
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.¶
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.¶
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:¶
Scope does not include:¶
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.¶
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.¶
This document does not request any IANA allocations.¶
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.¶