| Internet-Draft | Inter-domain SAVNET Problem Statement | March 2023 |
| Wu, et al. | Expires 5 September 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.¶
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.¶
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.¶
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) 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 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.
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.¶
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.¶
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.¶
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.¶
SAV at provider interface can utilize ACL-based ingress filtering and/or loose uRPF to prevent spoofing source addresses from provider AS.¶
+-----------+
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 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.¶
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.¶
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 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.¶
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 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 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.¶
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 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.¶
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 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.¶
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.¶
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.¶
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.¶
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.¶
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 used in the new SAV mechanism to achieve better SAV function.¶
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.¶
This document does not request any IANA allocations.¶
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.¶