RFC 8704
Enhanced Feasible-Path Unicast Reverse Path Forwarding
📜 RFC 8704: Enhanced Feasible-Path uRPF 💖
Okay bestie, gather round because this RFC is about making source address validation less of a headache for ISPs 💅✨
Quick tea on the title block first 🫶 It's Request for Comments 8704, a Best Current Practice (BCP 84) 🎀, published in February 2020 🌸. The authors are K. Sriram and D. Montgomery from USA NIST, plus J. Haas from Juniper Networks, Inc. 👑 It's an IETF stream document with ISSN 2070-1721, and it updates RFC 3704 🦋 It doesn't obsolete anything.
Abstract
Okay so the vibe here is: unicast Reverse Path Forwarding (uRPF) is how routers check whether a packet's source address is legit 🔍 (that's the whole source address spoofing thing, see BCP 38 💀). RFC 3704 gave us three flavors: strict uRPF is super rigid about directionality 🙅♀️, loose uRPF literally doesn't care about directionality at all 😭, and feasible-path uRPF tries to find a middle ground 🥹 But the feasible-path version still has shortcomings, and this doc is all about fixing that 🔧
So this is the enhanced feasible-path uRPF (EFP-uRPF) 💜 It's more flexible about directionality (in a meaningful way ✨) than the RFC 3704 version. The big goal is to cut down on false positives in source address validation (SAV), which means fewer innocent packets getting dropped 🙈 ISPs get less nervous about breaking their customers' service, and that's how we get more people actually deploying uRPF 🌈 Honestly it's giving protection against DoS and DDoS attacks 🛡️
Also, this document updates RFC 3704 🎀
Status of This Memo
This is a Best Current Practice 📌 It's an IETF product with consensus from the community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 💖 More BCP info lives in Section 2 of RFC 7841 🧚
You can check the current status, errata, and leave feedback at https://www.rfc-editor.org/info/rfc8704 🍓
Copyright Notice
Copyright (c) 2020 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) as they stand on the publication date 📜 Please read them carefully, because they spell out your rights and restrictions 🧐 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Simplified BSD License 💅
Table of Contents
1. Introduction
1.1. Terminology
1.2. Requirements Language
2. Review of Existing Source Address Validation Techniques
2.1. SAV Using Access Control List
2.2. SAV Using Strict Unicast Reverse Path Forwarding
2.3. SAV Using Feasible-Path Unicast Reverse Path Forwarding
2.4. SAV Using Loose Unicast Reverse Path Forwarding
2.5. SAV Using VRF Table
3. SAV Using Enhanced Feasible-Path uRPF
3.1. Description of the Method
3.1.1. Algorithm A: Enhanced Feasible-Path uRPF
3.2. Operational Recommendations
3.3. A Challenging Scenario
3.4. Algorithm B: Enhanced Feasible-Path uRPF with Additional
Flexibility across Customer Cone
3.5. Augmenting RPF Lists with ROA and IRR Data
3.6. Implementation and Operations Considerations
3.6.1. Impact on FIB Memory Size Requirement
3.6.2. Coping with BGP's Transient Behavior
3.7. Summary of Recommendations
3.7.1. Applicability of the EFP-uRPF Method with Algorithm A
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction 🌸
Source address validation (SAV) is all about detecting and mitigating source address (SA) spoofing [RFC2827] 🕵️♀️ This document wants to improve the unicast Reverse Path Forwarding (uRPF) techniques [RFC3704] used for SAV. Strict uRPF is inflexible about directionality (see [RFC3704] for definitions), loose uRPF is oblivious to directionality, and the current feasible-path uRPF tries to strike a balance between the two [RFC3704] 🥺 But as we'll see, the existing feasible-path uRPF still has shortcomings. Even with it, ISPs are often nervous that they might be dropping customers' data packets that have legit source addresses 😰
So this document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that aim to be more flexible (in a meaningful way) about directionality than the feasible-path uRPF 💖 The core principle is this: if BGP updates for multiple prefixes with the same origin AS were received on different interfaces at border routers, then incoming data packets with source addresses in any of those prefixes should be accepted on any of those interfaces ✨ (More on this in Section 3.) For some tricky ISP-customer scenarios (see Section 3.3), there's also a more relaxed version, Section 3.4 🦋 Implementation and operations considerations are in Section 3.6 🍓
The routes under consideration are assumed to have been vetted based on prefix filtering [RFC7454] and possibly origin validation [RFC6811] 🔍 Throughout this document, that's the baseline 🫶
The EFP-uRPF methods aim to significantly reduce false positives in SAV detection 🙈 They should add operational robustness and efficacy to uRPF while easing ISPs' worries about accidentally disrupting customer service 💅 That should encourage more uRPF deployment, which helps realize its Denial of Service (DoS) and Distributed DoS (DDoS) prevention benefits across the whole network 🛡️✨
1.1. Terminology 💜
The Reverse Path Forwarding (RPF) list is the list of permissible source-address prefixes for incoming data packets on a given interface 🧚
Peering relationships in this document are provider-to-customer (P2C), customer-to-provider (C2P), and peer-to-peer (P2P) 🌈 Here, "provider" means a transit provider. The first two are transit relationships 🚚 A peer connected via a P2P link is called a lateral peer (non-transit) 🤝
AS A's customer cone is A plus all the ASes that can be reached from A following only P2C links [Luckie] 👑
A stub AS is an AS with no customers and no lateral peers 🌱 In this document, a single-homed stub AS has a single transit provider, and a multihomed stub AS has multiple (two or more) transit providers 🏠
1.2. 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 📏 This is the one place where capitals actually matter, bestie 😤
2. Review of Existing Source Address Validation Techniques 🔎
There are a bunch of existing techniques for mitigating DoS/DDoS attacks that use spoofed addresses [RFC2827] [RFC3704] 💀 SAV happens in network edge devices like border routers, Cable Modem Termination Systems (CMTS) [RFC4036], and Packet Data Network Gateways (PDN-GWs) in mobile networks [Firmin] 📱 Ingress Access Control List (ACL) and uRPF are the techniques used to implement SAV [RFC2827] [RFC3704] [ISOC] ✨
2.1. SAV Using Access Control List 🧾
Ingress/egress ACLs are maintained to list acceptable (or alternatively, unacceptable) prefixes for the source addresses in incoming/outgoing Internet Protocol (IP) packets 📋 Any packet whose source address fails the filtering criteria gets dropped 🗑️ The ingress/egress filters' ACLs need to be kept up to date, and updating them is an operator-driven manual process 😩 So it's operationally difficult or outright infeasible, no cap 🙃
Typically, egress ACLs in access aggregation devices (e.g., CMTS, PDN-GW) only permit source addresses from the address spaces (prefixes) associated with the interface the customer network connects to 🔐 Ingress ACLs are usually deployed on border routers and drop ingress packets when the source address is spoofed (e.g., it belongs to obviously disallowed prefix blocks, IANA special-purpose prefixes [SPAR-v4][SPAR-v6], the provider's own prefixes, etc.) 🚫
🫶 That's the first chunk, bestie! Part 2 is coming up next, so stay tuned 💖🧚
2.2. SAV Using Strict Unicast Reverse Path Forwarding ✨
Okay bestie, before we dive into the scenarios, here's the lingo we're using in the figures 🦋
- "fails" means drops packets with legitimate source addresses 💀
- "works (but not desirable)" means it lets through every packet with a legit source address, but it doesn't care about directionality 🙈
- "works best" means it lets through every packet with a legit source address with no (or minimal) directionality compromise 👑
- The notation
Pi[ASn ASm ...]is a BGP update for prefix Pi, with the AS_PATH shown in the square brackets 🧚
So, strict uRPF is giving very strict 💅 A packet hitting a border router only gets in if the FIB (Forwarding Information Base) has a prefix covering its source address, AND the forwarding info for that prefix points back out the same interface the packet came in on. Basically the reverse path to the source should use the same interface the packet arrived on. Sounds clean, but it has known problems when you're multihomed, when routes aren't announced symmetrically to all your transit providers, and when data packets take asymmetric routes. 😭
Here's how the asymmetric routing happens (see Figure 1 🌸). A customer AS announces one prefix (P1) to one transit provider (ISP-a), and a different prefix (P2) to another transit provider (ISP-b). But then it sends data packets with source addresses in P2 to the first provider (ISP-a), or vice versa. Now any data packet with a source address in P2 that arrives at AS2 directly from AS1 gets dropped. And any data packet with a source address in P1 that starts at AS1 and goes through AS3 to reach AS2 also gets dropped at AS2. Rude 😤
+------------+ ---- P1[AS2 AS1] ---> +------------+
| AS2(ISP-a) | <----P2[AS3 AS1] ---- | AS3(ISP-b) |
+------------+ +------------+
/\ /\
\ /
\ /
\ /
P1[AS1]\ /P2[AS1]
\ /
+-----------------------+
| AS1(customer) |
+-----------------------+
P1, P2 (prefixes originated)Now let's check how each method handles data packets received at AS2 that come (1) from AS1 with a source address (SA) in P2, or (2) from AS3 that originated from AS1 with a SA in P1 🧐
- Strict uRPF fails
- Feasible-path uRPF fails
- Loose uRPF works (but not desirable)
- Enhanced feasible-path uRPF works best
Figure 1: Scenario 1 for Illustration of Efficacy of uRPF Schemes
2.3. SAV Using Feasible-Path Unicast Reverse Path Forwarding 🎀
Feasible-path uRPF is the glow-up that partially fixes the multihoming problem from strict uRPF ✨ It works like strict uRPF, but on top of the best-path prefix, it also adds prefixes from alternative announced routes into the RPF list. This only works if either (a) announcements for the same prefixes (some of which may be prepended to make them less preferred) reach all the transit providers doing feasible-path uRPF checks, or (b) an aggregate, less-specific prefix is announced to all transit providers while more-specific prefixes covered by it are announced to different transit providers, as needed for traffic engineering.
Let's look at the multihoming scenario (Scenario 2, see Figure 2 💖). If the customer AS announces routes for both prefixes (P1, P2) to both transit providers (with suitable prepends if traffic engineering needs them), then feasible-path uRPF works. Important catch though: in this scenario it only works if AS2 and AS3 prefer customer routes over a shorter non-customer route. The method also has limitations of its own. One form happens naturally when recommendation (a) or (b) above isn't followed about how prefixes get propagated.
The other form goes like this. In Scenario 2, it's possible that the second transit provider (ISP-b or AS3) doesn't propagate the prepended route for prefix P1 to the first transit provider (ISP-a or AS2). Why? AS3's decision policy can prioritize a shorter route to P1 via a lateral peer (AS2) over a longer route learned directly from the customer (AS1). In that case AS3 wouldn't send any route announcement for P1 to AS2 (over the P2P link). So a data packet with a source address in P1 that starts at AS1 and goes through AS3 to AS2 gets dropped at AS2. Plot twist, nobody's happy 😭
+------------+ routes for P1, P2 +------------+
| AS2(ISP-a) |<-------------------->| AS3(ISP-b) |
+------------+ (P2P) +------------+
/\ /\
\ /
P1[AS1]\ /P2[AS1]
\ /
P2[AS1 AS1 AS1]\ /P1[AS1 AS1 AS1]
\ /
+-----------------------+
| AS1(customer) |
+-----------------------+
P1, P2 (prefixes originated)Consider data packets received at AS2 via AS3 that originated from AS1 and have a source address in P1:
- Feasible-path uRPF works (if the customer route to P1 is preferred at AS3 over the shorter path)
- Feasible-path uRPF fails (if the shorter path to P1 is preferred at AS3 over the customer route)
- Loose uRPF works (but not desirable)
- Enhanced feasible-path uRPF works best
Figure 2: Scenario 2 for Illustration of Efficacy of uRPF Schemes
2.4. SAV Using Loose Unicast Reverse Path Forwarding 🌈
Loose uRPF is the chill one 😌 Here, an ingress packet at the border router is accepted only if the FIB has one or more prefixes that encompass the source address. Basically, a packet gets dropped only if there's no route in the FIB for its source address. The tradeoff is that loose uRPF sacrifices directionality. It only drops packets when the source address is unreachable in the current FIB (for example, IANA special-purpose prefixes [SPAR-v4][SPAR-v6], unallocated addresses, or allocated addresses that aren't currently routed) 🍓
2.5. SAV Using VRF Table 🧚
VRF (Virtual Routing and Forwarding) technology [RFC4364] [Juniper] lets a router keep multiple routing table instances, separate from the global RIB (Routing Information Base) 🌸 eBGP (External BGP) peering sessions send specific routes to be stored in a dedicated VRF table, and the uRPF process checks that VRF table (instead of the FIB) for source address validation. A VRF table can be dedicated to each eBGP peer and used for uRPF for only that peer, which gives you strict mode operation. For loose uRPF on an interface, the matching VRF table would be global, meaning it holds the same routes as the FIB ✨
3. SAV Using Enhanced Feasible-Path uRPF ✨
3.1. Description of the Method 🎀
Okay so the enhanced feasible-path uRPF (EFP-uRPF) method is giving major upgrade energy 💅 It adds greater operational robustness and efficacy to the existing uRPF methods we covered in Section 2, and the reason is that it avoids dropping legit data packets and compromising directionality 🙈 The main idea is that if BGP updates for multiple prefixes with the same origin AS came in on different interfaces (at border routers), then incoming data packets with source addresses in any of those prefixes should be accepted on any of those interfaces ✨ The best way to see it is with an example, so let's go 🍓
Say a border router of ISP-A has, in its Adj-RIBs-In [RFC4271], the set of prefixes {Q1, Q2, Q3}. Each one has AS-x as its origin, and AS-x is in ISP-A's customer cone 👑 Out of that set, the router got the route for prefix Q1 over a customer-facing interface, but it learned the routes for Q2 and Q3 from a lateral peer and an upstream transit provider, respectively. In this scenario, the enhanced feasible-path uRPF method requires Q1, Q2, and Q3 to be included in the RPF list for the customer interface under consideration 💖
So the EFP-uRPF method gathers feasible paths for customer interfaces in a more precise way (compared to the feasible-path uRPF), which means all legitimate packets get accepted while directionality stays intact 🫶
The EFP-uRPF method described above is recommended to be applied on customer interfaces. It can also be extended to build the RPF lists for lateral peer interfaces. In other words, the EFP-uRPF method can be applied (and loose uRPF avoided) on lateral peer interfaces. That helps avoid compromising directionality on lateral peer interfaces, which is unavoidable with loose uRPF (see Section 2.4) 🌸
Looking back at Scenarios 1 and 2 (Figures 1 and 2), the EFP-uRPF method works better than the other uRPF methods, periodt ✨ Scenario 3 (Figure 3) shows it with a more concrete example. Here we focus on how EFP-uRPF operates at ISP4 (AS4). ISP4 learns a route for prefix P1 via a C2P interface from customer ISP2 (AS2), and that route for P1 has origin AS1. ISP4 also learns a route for P2 via another C2P interface from customer ISP3 (AS3). On top of that, AS4 learns a route for P3 via a lateral P2P interface from ISP5 (AS5). All three prefixes share the same origin AS (that's AS1), so using the enhanced feasible-path uRPF scheme, AS4 includes all of these prefixes in the RPF list for the customer interfaces (from AS2 and AS3) 🧚
+----------+ P3[AS5 AS1] +------------+
| AS4(ISP4)|<---------------| AS5(ISP5) |
+----------+ (P2P) +------------+
/\ /\ /\
/ \ /
P1[AS2 AS1]/ \P2[AS3 AS1] /
(C2P)/ \(C2P) /
/ \ /
+----------+ +----------+ /
| AS2(ISP2)| | AS3(ISP3)| /
+----------+ +----------+ /
/\ /\ /
\ / /
P1[AS1]\ /P2[AS1] /P3[AS1]
(C2P)\ /(C2P) /(C2P)
\ / /
+----------------+ /
| AS1(customer) |/
+----------------+
P1, P2, P3 (prefixes originated)
Consider that data packets (sourced from AS1)
may be received at AS4 with a source address
in P1, P2, or P3 via any of the neighbors (AS2, AS3, AS5):
* Feasible-path uRPF fails
* Loose uRPF works (but not desirable)
* Enhanced feasible-path uRPF works best
Figure 3: Scenario 3 for Illustration of Efficacy of uRPF Schemes3.1.1. Algorithm A: Enhanced Feasible-Path uRPF ✨
The underlying algorithm for the solution method described above (Section 3.1) can be specified as follows. It's meant to be implemented in a transit AS 🦋
- Create the set of unique origin ASes, considering only the routes in the Adj-RIBs-In of customer interfaces. Call it
Set A = {AS1, AS2, ..., ASn}. - Considering all routes in Adj-RIBs-In for all interfaces (customer, lateral peer, and transit provider), form the set of unique prefixes that have a common origin AS1. Call it
Set X1. - Include
Set X1in the RPF list on all customer interfaces on which one or more of the prefixes inSet X1were received. - Repeat Steps 2 and 3 for each of the remaining ASes in
Set A(i.e., for ASi, where i = 2, ..., n).
The above algorithm can also be extended to apply the EFP-uRPF method to lateral peer interfaces. However, it's left up to the operator to decide whether they want EFP-uRPF or loose uRPF on lateral peer interfaces 🤷♀️ The loose uRPF method is recommended to be applied on transit provider interfaces 💜
3.2. Operational Recommendations 📋
The following operational recommendations will make the operation of the enhanced feasible-path uRPF robust 🔥
For multihomed stub AS:
- A multihomed stub AS should announce at least one of the prefixes it originates to each of its transit provider ASes. (It is understood that a single-homed stub AS would announce all prefixes it originates to its sole transit provider AS.)
For non-stub AS:
- A non-stub AS should also announce at least one of the prefixes it originates to each of its transit provider ASes.
- Additionally, from the routes it has learned from customers, a non-stub AS SHOULD announce at least one route per origin AS to each of its transit provider ASes.
3.3. A Challenging Scenario 😬
Okay, real talk, it's worth noticing that if ASes aren't following the recommendations above, there's a tricky scenario that gives the enhanced feasible-path uRPF (and traditional feasible-path uRPF too) a hard time. Check out Figure 4. Since routes for neither P1 nor P2 get propagated on the AS2-AS4 interface (because of the NO_EXPORT Community), the enhanced feasible-path uRPF at AS4 will reject data packets received on that interface with source addresses in P1 or P2 💀 (For a slightly more complex example, see slide #10 in [Sriram-URPF].)
+----------+
| AS4(ISP4)|
+----------+
/\ /\
/ \ P1[AS3 AS1]
P1 and P2 not / \ P2[AS3 AS1]
propagated / \ (C2P)
(C2P) / \
+----------+ +----------+
| AS2(ISP2)| | AS3(ISP3)|
+----------+ +----------+
/\ /\
\ / P1[AS1]
P1[AS1] NO_EXPORT \ / P2[AS1]
P2[AS1] NO_EXPORT \ / (C2P)
(C2P) \ /
+----------------+
| AS1(customer) |
+----------------+
P1, P2 (prefixes originated)
Consider that data packets (sourced from AS1)
may be received at AS4 with a source address
in P1 or P2 via AS2:
* Feasible-path uRPF fails
* Loose uRPF works (but not desirable)
* Enhanced feasible-path uRPF with Algorithm A fails
* Enhanced feasible-path uRPF with Algorithm B works best
Figure 4: Illustration of a Challenging Scenario3.4. Algorithm B: Enhanced Feasible-Path uRPF with Additional Flexibility across Customer Cone 🌈
Adding more flexibility to the enhanced feasible-path uRPF method can help with the potential limitation we just spotted using the scenario in Figure 4 (Section 3.3). In what follows, "route" refers to a route currently existing in the Adj-RIBs-In. With that extra flexibility, the modified algorithm, called Algorithm B (implemented in a transit AS), works like this 🧠
- Create the set of all directly connected customer interfaces. Call it
Set I = {I1, I2, ..., Ik}. - Create the set of all unique prefixes for which routes exist in Adj-RIBs-In for the interfaces in
Set I. Call itSet P = {P1, P2, ..., Pm}. - Create the set of all unique origin ASes seen in the routes that exist in Adj-RIBs-In for the interfaces in
Set I. Call itSet A = {AS1, AS2, ..., ASn}. - Create the set of all unique prefixes for which routes exist in Adj-RIBs-In of all lateral peer and transit provider interfaces, such that each of the routes has its origin AS belonging in
Set A. Call itSet Q = {Q1, Q2, ..., Qj}. - Then,
Set Z = Union(P,Q)is the RPF list that is applied for every customer interface inSet I.
When Algorithm B (which is more flexible than Algorithm A) is used on customer interfaces, the type of limitation shown in Figure 4 (Section 3.3) gets overcome and the method works 🎉 The directionality property is minimally compromised, but the EFP-uRPF method with Algorithm B is still a way better choice for this scenario than loose uRPF, which doesn't care about directionality at all 🙅♀️
So, applying the EFP-uRPF method with Algorithm B is recommended on customer interfaces for challenging scenarios like the ones described in Section 3.3 💖
3.5. Augmenting RPF Lists with ROA and IRR Data 📚
It's worth emphasizing that an indirect part of the proposal in this document is that RPF filters may be augmented from secondary sources 🫶 So the construction of RPF lists using either method proposed in this document (Algorithm A or B) can be augmented with data from Route Origin Authorization (ROA) [RFC6482], as well as Internet Routing Registry (IRR) data. Be extra careful with IRR data, though, because it's not always accurate or trusted 👀
For EFP-uRPF with Algorithm A (see Section 3.1.1): if a ROA includes prefix Pi and ASj, then augment the RPF list of each customer interface on which at least one route with origin ASj was received with prefix Pi.
For EFP-uRPF with Algorithm B: if ASj belongs in Set A (see Step #3 Section 3.4) and if a ROA includes prefix Pi and ASj, then augment the RPF list Z in Step 5 of Algorithm B with prefix Pi.
Similar procedures can be followed with reliable IRR data as well. This helps make the RPF lists more robust about source addresses that customers of the ISP may legitimately use 🌸
3.6. Implementation and Operations Considerations 🛠️
3.6.1. Impact on FIB Memory Size Requirement 💾
okay so the existing RPF checks in edge routers already ride on what line cards do today 🧚. For the enhanced feasible-path uRPF, the big thing the line cards need is the ability to take arbitrary RPF lists, which don't have to match what's already in the FIB 💅. In the algorithms in Sections 3.1.1 and 3.4, the RPF lists are built by applying a set of rules to all received BGP routes, not just the ones picked as best path and installed in the FIB ✨. Querying an RPF list instead of the FIB is basically like uRPF querying a VRF table (see Section 2.5) 🦋.
The techniques here need extra memory, specifically ternary content-addressable memory (i.e., TCAM), so the line cards have space to store those RPF lists 🎀. For an ISP's AS, each line card's RPF list size will roughly equal the total number of originated prefixes from ASes in its customer cone, assuming Algorithm B in Section 3.4 is used 🌸. (Note: EFP-uRPF with Algorithm A (see Section 3.1.1) needs way less memory than EFP-uRPF with Algorithm B 🫶.)
Here's the measured customer cone sizes (number of prefixes originated from all ASes in the cone) for different ISP types [Sriram-RIPE63] 👑:
+------------+---------------------------------------+
| Type of | Measured Customer Cone Size in # |
| ISP | Prefixes (in turn this is an estimate |
| | for RPF list size on the line card) |
+============+=======================================+
| Very Large | 32393 |
| Global ISP | |
| #1 | |
+------------+---------------------------------------+
| Very Large | 29528 |
| Global ISP | |
| #2 | |
+------------+---------------------------------------+
| Large | 20038 |
| Global ISP | |
+------------+---------------------------------------+
| Mid-size | 8661 |
| Global ISP | |
+------------+---------------------------------------+
| Regional | 1101 |
| ISP (in | |
| Asia) | |
+------------+---------------------------------------+
Table 1: Customer Cone Sizes (# Prefixes) for
Various Types of ISPsFor some super large global ISPs sitting at the core of the Internet, the customer cone size (# prefixes) can be as high as a few hundred thousand [CAIDA] 🌈. But uRPF works best at ASes at the edges of the Internet, where the cones are smaller, as shown in Table 1 🍓.
A very large global ISP's line card is likely to have a FIB big enough for 2 million routes [Cisco1] 💖. The line cards in a large global ISP, a midsize global ISP, and a regional ISP are likely to have FIBs that fit about 1 million, 0.5 million, and 100k routes, respectively [Cisco2] ✨. Put those FIB numbers next to the RPF list numbers in Table 1 and it can be surmised that the conservatively estimated RPF list is only a small fraction of the expected FIB memory under relevant ISP scenarios 🙈. What counts as a relevant ISP scenario here is that only smaller ISPs (and maybe some midsize and regional ones) are expected to use the proposed EFP-uRPF method, since it works best closer to the edges of the Internet 🧚.
3.6.2. Coping with BGP's Transient Behavior 🌀
BGP announcements can be a little unpredictable 😭. Routes may get withdrawn temporarily and then reannounced because of transient stuff like a BGP session reset or recovering from a link failure. To handle that, hysteresis should be introduced when maintaining the RPF lists 🦋. When responding to route withdrawals, deleting entries from the RPF lists SHOULD be delayed by a predetermined amount (a value based on operational experience) 💅. This should help suppress the effects of BGP transients 🫶.
3.7. Summary of Recommendations 📝
Depending on the scenario, an ISP or enterprise AS operator should follow one of these recommendations about uRPF/SAV 👑:
- For directly connected networks, i.e., subnets directly connected to the AS, the AS under consideration SHOULD perform ACL-based SAV 🎀.
- For a directly connected single-homed stub AS (customer), the AS under consideration SHOULD perform SAV based on the strict uRPF method 🌸.
- For all other scenarios:
- The EFP-uRPF method with Algorithm B (see Section 3.4) SHOULD be applied on customer interfaces 💖.
- The loose uRPF method SHOULD be applied on lateral peer and transit provider interfaces ✨.
It's also recommended that prefixes from registered ROAs and IRR route objects that include ASes in an ISP's customer cone SHOULD be used to augment the pertaining RPF lists (see Section 3.5 for details) 🫶.
3.7.1. Applicability of the EFP-uRPF Method with Algorithm A 🧚
The EFP-uRPF method with Algorithm A isn't in the list of recommendations above 🙈. It's an alternative to EFP-uRPF with Algorithm B and can be used in limited circumstances 🦋. It's expected to work fine if an ISP deploying it only has multihomed stub customers 💅. It's trivially equivalent to strict uRPF if an ISP deploys it for a single-homed stub customer 🍓. More generally, it's also expected to work fine when none of the limitations in Section 3.3 apply 🌈.
Caution: even if those limitations aren't expected at deployment time, the vulnerability to changing conditions is still there, so be careful with EFP-uRPF with Algorithm A 😭. It may be difficult for an ISP to know or track how much NO_EXPORT (see Section 3.3) is used on routes within its customer cone 👑. If an ISP decides to use EFP-uRPF with Algorithm A, it should make its direct customers aware of the operational recommendations in Section 3.2 🎀. That means the ISP tells direct customers that at least one prefix originated by each AS in the direct customer's customer cone must propagate to the ISP 🫶.
On a lateral peer interface, an ISP may choose to apply the EFP-uRPF method with Algorithm A (with appropriate modification of the algorithm) 🌸. Some ISPs may think stricter forms of uRPF than loose uRPF are applicable on interfaces with lateral peers, which is why this is allowed ✨.
4. Security Considerations 🔐
The security considerations in BCP 38 [RFC2827] and RFC 3704 [RFC3704] apply to this document as well 💀. On top of that, if you're thinking about using the EFP-uRPF method with Algorithm A, an ISP or AS operator should be aware of the applicability considerations and potential vulnerabilities discussed in Section 3.7.1 😭.
When augmenting RPF lists with ROA (and possibly reliable IRR) information (see Section 3.5), we're trading off in favor of fewer false positives (regarding invalid detection in SAV) 🫶. The price is another slight risk: a malicious actor at another AS in the neighborhood, within the customer cone, might take advantage of the augmented prefix to some extent 🙈. This risk also exists for normal announced prefixes (i.e., without ROA augmentation) with any uRPF method other than strict uRPF 💅. It's mitigated, though, if the transit provider of that other AS is performing SAV ✨.
Security hardening of routers and other supporting systems (e.g., Resource PKI (RPKI) and ROA management systems) against compromise is out of scope for this document, but it's extremely important 🔥. If those systems get compromised, it can affect the operation and performance of the SAV methods described here 💀.
5. IANA Considerations 🧚
This document has no IANA actions 🌸.
6. References 📚
6.1. Normative References 💜
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.6.2. Informative References 📚
okay bestie, these ones aren't required reading, but they give you the context behind the document 🧚
[CAIDA] CAIDA, "Information for AS 174 (COGENT-174)", October 2019, <https://spoofer.caida.org/as.php?asn=174>.
[Cisco1] Cisco, "Internet Routing Table Growth Causes %ROUTING-FIB-4-RSRC_LOW Message on Trident-Based Line Cards", January 2014, <https://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/116999-problem-line-card-00.html>.
[Cisco2] Cisco, "Cisco Nexus 7000 Series NX-OS Unicast Routing Configuration Guide, Release 5.x (Chapter 15: 'Managing the Unicast RIB and FIB')", March 2018, <https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/unicast/configuration/guide/l3_cli_nxos/l3_NewChange.html>.
[Firmin] Firmin, F., "The Evolved Packet Core", <https://www.3gpp.org/technologies/keywords-acronyms/100-the-evolved-packet-core>.
[ISOC] Internet Society, "Addressing the challenge of IP spoofing", September 2015, <https://www.internetsociety.org/resources/doc/2015/addressing-the-challenge-of-ip-spoofing/>.
[Juniper] Juniper Networks, "Creating Unique VPN Routes Using VRF Tables", May 2019, <https://www.juniper.net/documentation/en_US/junos/topics/topic-map/l3-vpns-routes-vrf-tables.html#id-understanding-virtual-routing-and-forwarding-tables>.
[Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and kc. claffy, "AS Relationships, customer cones, and validation", In Proceedings of the 2013 Internet Measurement Conference, DOI 10.1145/2504730.2504735, October 2013, <https://dl.acm.org/doi/10.1145/2504730.2504735>.
[RFC4036] Sawyer, W., "Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management", RFC 4036, DOI 10.17487/RFC4036, April 2005, <https://www.rfc-editor.org/info/rfc4036>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, <https://www.rfc-editor.org/info/rfc7454>.
[SPAR-v4] IANA, "IANA IPv4 Special-Purpose Address Registry", <https://www.iana.org/assignments/iana-ipv4-special-registry/>.
[SPAR-v6] IANA, "IANA IPv6 Special-Purpose Address Registry", <https://www.iana.org/assignments/iana-ipv6-special-registry/>.
[Sriram-RIPE63] Sriram, K. and R. Bush, "Estimating CPU Cost of BGPSEC on a Router", Presented at RIPE 63 and at the SIDR WG meeting at IETF 83, March 2012, <http://www.ietf.org/proceedings/83/slides/slides-83-sidr-7.pdf>.
[Sriram-URPF] Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Filtering", Presented at the OPSEC WG meeting at IETF 101, March 2018, <https://datatracker.ietf.org/meeting/101/materials/slides-101-opsec-draft-sriram-opsec-urpf-improvements-00>.
Acknowledgements 🫶
the authors wanna give a huge shoutout to these legends for their comments and suggestions 💖 Sandy Murphy, Alvaro Retana, Job Snijders, Marco Marzetti, Marco d'Itri, Nick Hilliard, Gert Doering, Fred Baker, Igor Gashinsky, Igor Lubashev, Andrei Robachevsky, Barry Greene, Amir Herzberg, Ruediger Volk, Jared Mauch, Oliver Borchert, Mehmet Adalier, and Joel Jaeggli 👑. The comments and suggestions from the IESG reviewers are also SO appreciated 🌸
Authors' Addresses 🎀
Kotikalapudi Sriram
USA National Institute of Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899
United States of America
Email: ksriram@nist.govDoug Montgomery
USA National Institute of Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899
United States of America
Email: dougm@nist.govJeffrey Haas
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: jhaas@juniper.net📦 where this page comes from
- ietf: rfc8704 2020-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms