idnits 2.17.00 (12 Aug 2021) /tmp/idnits3420/draft-ietf-opsec-urpf-improvements-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3704, updated by this document, for RFC5378 checks: 2003-05-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 30, 2019) is 988 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'AS2 AS1' is mentioned on line 389, but not defined == Missing Reference: 'AS3 AS1' is mentioned on line 479, but not defined == Missing Reference: 'AS1' is mentioned on line 488, but not defined == Missing Reference: 'AS5 AS1' is mentioned on line 384, but not defined Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSEC Working Group K. Sriram 3 Internet-Draft D. Montgomery 4 BCP: 84 (if approved) USA NIST 5 Updates: 3704 (if approved) J. Haas 6 Intended status: Best Current Practice Juniper Networks, Inc. 7 Expires: March 2, 2020 August 30, 2019 9 Enhanced Feasible-Path Unicast Reverse Path Forwarding 10 draft-ietf-opsec-urpf-improvements-04 12 Abstract 14 This document identifies a need for and proposes improvement of the 15 unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for 16 detection and mitigation of source address spoofing (see BCP 38). 17 The strict uRPF is inflexible about directionality, the loose uRPF is 18 oblivious to directionality, and the current feasible-path uRPF 19 attempts to strike a balance between the two (see RFC 3704). 20 However, as shown in this document, the existing feasible-path uRPF 21 still has shortcomings. This document describes enhanced feasible- 22 path uRPF (EFP-uRPF) techniques, which are more flexible (in a 23 meaningful way) about directionality than the feasible-path uRPF (RFC 24 3704). The proposed EFP-uRPF methods aim to significantly reduce 25 false positives regarding invalid detection in source address 26 validation (SAV). Hence they can potentially alleviate ISPs' 27 concerns about the possibility of disrupting service for their 28 customers, and encourage greater deployment of uRPF techniques. This 29 document updates RFC 3704. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 2, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 2. Review of Existing Source Address Validation Techniques . . . 4 69 2.1. SAV using Access Control List . . . . . . . . . . . . . . 4 70 2.2. SAV using Strict Unicast Reverse Path Forwarding . . . . 5 71 2.3. SAV using Feasible-Path Unicast Reverse Path Forwarding . 6 72 2.4. SAV using Loose Unicast Reverse Path Forwarding . . . . . 7 73 2.5. SAV using VRF Table . . . . . . . . . . . . . . . . . . . 8 74 3. SAV using Enhanced Feasible-Path uRPF . . . . . . . . . . . . 8 75 3.1. Description of the Method . . . . . . . . . . . . . . . . 8 76 3.1.1. Algorithm A: Enhanced Feasible-Path uRPF . . . . . . 10 77 3.2. Operational Recommendations . . . . . . . . . . . . . . . 10 78 3.3. A Challenging Scenario . . . . . . . . . . . . . . . . . 11 79 3.4. Algorithm B: Enhanced Feasible-Path uRPF with Additional 80 Flexibility Across Customer Cone . . . . . . . . . . . . 12 81 3.5. Augmenting RPF Lists with ROA and IRR Data . . . . . . . 12 82 3.6. Implementation and Operations Considerations . . . . . . 13 83 3.6.1. Impact on FIB Memory Size Requirement . . . . . . . . 13 84 3.6.2. Coping with BGP's Transient Behavior . . . . . . . . 14 85 3.7. Summary of Recommendations . . . . . . . . . . . . . . . 15 86 3.7.1. Applicability of the enhanced feasible-path uRPF 87 (EFP-uRPF) method with Algorithm A . . . . . . . . . 15 88 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 90 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 93 7.2. Informative References . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 96 1. Introduction 98 Source Address Validation (SAV) refers to the detection and 99 mitigation of source address (SA) spoofing [RFC2827]. This document 100 identifies a need for and proposes improvement of improvement of the 101 unicast Reverse Path Forwarding (uRPF) techniques [RFC3704] for SAV. 102 The strict uRPF is inflexible about directionality (see [RFC3704] for 103 definitions), the loose uRPF is oblivious to directionality, and the 104 current feasible-path uRPF attempts to strike a balance between the 105 two [RFC3704]. However, as shown in this document, the existing 106 feasible-path uRPF still has shortcomings. Even with the feasible- 107 path uRPF, ISPs are often apprehensive that they may be dropping 108 customers' data packets with legitimate source addresses. 110 This document describes an enhanced feasible-path uRPF (EFP-uRPF) 111 technique, which aims to be more flexible (in a meaningful way) about 112 directionality than the feasible-path uRPF. It is based on the 113 principle that if BGP updates for multiple prefixes with the same 114 origin AS were received on different interfaces (at border routers), 115 then incoming data packets with source addresses in any of those 116 prefixes should be accepted on any of those interfaces (presented in 117 Section 3). For some challenging ISP-customer scenarios (see 118 Section 3.3), this document also describes a more relaxed version of 119 the enhanced feasible-path uRPF technique (presented in Section 3.4). 120 Implementation and operations considerations are discussed in 121 Section 3.6. 123 Throughout this document, the routes under consideration are assumed 124 to have been vetted based on prefix filtering [RFC7454] and possibly 125 origin validation [RFC6811]. 127 The EFP-uRPF methods aim to significantly reduce false positives 128 regarding invalid detection in SAV. They are expected to add greater 129 operational robustness and efficacy to uRPF, while minimizing ISPs' 130 concerns about accidental service disruption for their customers. It 131 is expected that this will encourage more deployment of uRPF to help 132 realize its DDoS prevention benefits network wide. 134 1.1. Terminology 136 Reverse Path Forwarding (RPF) list: The list of permissible source- 137 address prefixes for incoming data packets on a given interface. 139 Peering relationships considered in this document are provider-to- 140 customer (P2C), customer-to-provider (C2P), and peer-to-peer (p2p). 141 Provider here refers to transit provider. The first two are transit 142 relationships. A peer connected via a p2p link is known as a lateral 143 peer (non-transit). 145 Customer Cone: AS A's customer cone is A plus all the ASes that can 146 be reached from A following only P2C links [Luckie]. 148 A stub AS is an AS that does not have any customers or lateral peers. 149 In this document, a single-homed stub AS is one that has a single 150 transit provider and a multi-homed stub AS is one that has multiple 151 (two or more) transit providers. 153 1.2. Requirements Language 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in BCP 158 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 2. Review of Existing Source Address Validation Techniques 163 There are various existing techniques for mitigation against DDoS 164 attacks with spoofed addresses [RFC2827] [RFC3704]. Source address 165 validation (SAV) is performed in network edge devices such as border 166 routers, Cable Modem Termination Systems (CMTS) [RFC4036], and Packet 167 Data Network gateways (PDN-GW) in mobile networks [Firmin]. Ingress 168 Access Control List (ACL) and unicast Reverse Path Forwarding (uRPF) 169 are techniques employed for implementing SAV [RFC2827] [RFC3704] 170 [ISOC]. 172 2.1. SAV using Access Control List 174 Ingress/egress Access Control Lists (ACLs) are maintained to list 175 acceptable (or alternatively, unacceptable) prefixes for the source 176 addresses in the incoming/outgoing Internet Protocol (IP) packets. 177 Any packet with a source address that fails the filtering criteria is 178 dropped. The ACLs for the ingress/egress filters need to be 179 maintained to keep them up to date. Updating the ACLs is an 180 operator-driven manual process, and hence operationally difficult or 181 infeasible. 183 Typically, the egress ACLs in access aggregation devices (e.g., CMTS, 184 PDN-GW) permit source addresses only from the address spaces 185 (prefixes) that are associated with the interface on which the 186 customer network is connected. Ingress ACLs are typically deployed 187 on border routers, and drop ingress packets when the source address 188 is spoofed (e.g., belongs to obviously disallowed prefix blocks, IANA 189 special-purpose prefixes [SPAR-v4][SPAR-v6], provider's own prefixes, 190 etc.). 192 2.2. SAV using Strict Unicast Reverse Path Forwarding 194 Note: In the figures (scenarios) in this section and the subsequent 195 sections, the following terminology is used: "fails" means drops 196 packets with legitimate source addresses; "works (but not desirable)" 197 means passes all packets with legitimate source addresses but is 198 oblivious to directionality; "works best" means passes all packets 199 with legitimate source addresses with no (or minimal) compromise of 200 directionality. Further, the notation Pi[ASn ASm ...] denotes a BGP 201 update with prefix Pi and an AS_PATH as shown in the square brackets. 203 In the strict unicast Reverse Path Forwarding (uRPF) method, an 204 ingress packet at a border router is accepted only if the Forwarding 205 Information Base (FIB) contains a prefix that encompasses the source 206 address, and forwarding information for that prefix points back to 207 the interface over which the packet was received. In other words, 208 the reverse path for routing to the source address (if it were used 209 as a destination address) should use the same interface over which 210 the packet was received. It is well known that this method has 211 limitations when networks are multi-homed, routes are not 212 symmetrically announced to all transit providers, and there is 213 asymmetric routing of data packets. Asymmetric routing occurs (see 214 Figure 1) when a customer AS announces one prefix (P1) to one transit 215 provider (ISP-a) and a different prefix (P2) to another transit 216 provider (ISP-b), but routes data packets with source addresses in 217 the second prefix (P2) to the first transit provider (ISP-a) or vice 218 versa. Then data packets with source address in prefix P2 that are 219 received directly from AS1 will get dropped. Further, data packets 220 with source address in prefix P1 that originate from AS1 and traverse 221 via AS3 to AS2 will also get dropped at AS2. 223 +------------+ ---- P1[AS2 AS1] ---> +------------+ 224 | AS2(ISP-a) | <----P2[AS3 AS1] ---- | AS3(ISP-b)| 225 +------------+ +------------+ 226 /\ /\ 227 \ / 228 \ / 229 \ / 230 P1[AS1]\ /P2[AS1] 231 \ / 232 +-----------------------+ 233 | AS1(customer) | 234 +-----------------------+ 235 P1, P2 (prefixes originated) 237 Consider data packets received at AS2 238 (1) from AS1 with source address (SA) in P2, or 239 (2) from AS3 that originated from AS1 with SA in P1: 240 * Strict uRPF fails 241 * Feasible-path uRPF fails 242 * Loose uRPF works (but not desirable) 243 * Enhanced Feasible-path uRPF works best 245 Figure 1: Scenario 1 for illustration of efficacy of uRPF schemes. 247 2.3. SAV using Feasible-Path Unicast Reverse Path Forwarding 249 The feasible-path uRPF technique helps partially overcome the problem 250 identified with the strict uRPF in the multi-homing case. The 251 feasible-path uRPF is similar to the strict uRPF, but in addition to 252 inserting the best-path prefix, additional prefixes from alternative 253 announced routes are also included in the RPF list. This method 254 relies on either (a) announcements for the same prefixes (albeit some 255 may be prepended to effect lower preference) propagating to all 256 transit providers performing feasible-path uRPF checks, or (b) 257 announcement of an aggregate less specific prefix to all transit 258 providers while announcing more specific prefixes (covered by the 259 less specific prefix) to different transit providers as needed for 260 traffic engineering. As an example, in the multi-homing scenario 261 (see Scenario 2 in Figure 2), if the customer AS announces routes for 262 both prefixes (P1, P2) to both transit providers (with suitable 263 prepends if needed for traffic engineering), then the feasible-path 264 uRPF method works. It should be mentioned that the feasible-path 265 uRPF works in this scenario only if customer routes are preferred at 266 AS2 and AS3 over a shorter non-customer route. However, the 267 feasible-path uRPF method has limitations as well. One form of 268 limitation naturally occurs when the recommendation (a) or (b) 269 mentioned above regarding propagation of prefixes is not followed. 270 Another form of limitation can be described as follows. In Scenario 271 2 (described here, illustrated in Figure 2), it is possible that the 272 second transit provider (ISP-b or AS3) does not propagate the 273 prepended route for prefix P1 to the first transit provider (ISP-a or 274 AS2). This is because AS3's decision policy permits giving priority 275 to a shorter route to prefix P1 via a lateral peer (AS2) over a 276 longer route learned directly from the customer (AS1). In such a 277 scenario, AS3 would not send any route announcement for prefix P1 to 278 AS2 (over the p2p link). Then a data packet with source address in 279 prefix P1 that originates from AS1 and traverses via AS3 to AS2 will 280 get dropped at AS2. 282 +------------+ routes for P1, P2 +-----------+ 283 | AS2(ISP-a) |<-------------------->| AS3(ISP-b)| 284 +------------+ (p2p) +-----------+ 285 /\ /\ 286 \ / 287 P1[AS1]\ /P2[AS1] 288 \ / 289 P2[AS1 AS1 AS1]\ /P1[AS1 AS1 AS1] 290 \ / 291 +-----------------------+ 292 | AS1(customer) | 293 +-----------------------+ 294 P1, P2 (prefixes originated) 296 Consider data packets received at AS2 via AS3 297 that originated from AS1 and have source address in P1: 298 * Feasible-path uRPF works (if customer route to P1 299 is preferred at AS3 over shorter path) 300 * Feasible-path uRPF fails (if shorter path to P1 301 is preferred at AS3 over customer route) 302 * Loose uRPF works (but not desirable) 303 * Enhanced Feasible-path uRPF works best 305 Figure 2: Scenario 2 for illustration of efficacy of uRPF schemes. 307 2.4. SAV using Loose Unicast Reverse Path Forwarding 309 In the loose unicast Reverse Path Forwarding (uRPF) method, an 310 ingress packet at the border router is accepted only if the FIB has 311 one or more prefixes that encompass the source address. That is, a 312 packet is dropped if no route exists in the FIB for the source 313 address. Loose uRPF sacrifices directionality. It only drops 314 packets if the source address is unreachable in the current FIB 315 (e.g., IANA special-purpose prefixes [SPAR-v4][SPAR-v6], unallocated, 316 allocated but currently not routed). 318 2.5. SAV using VRF Table 320 The Virtual Routing and Forwarding (VRF) technology [RFC4364] 321 [Juniper] allows a router to maintain multiple routing table 322 instances separate from the global Routing Information Base (RIB). 323 External BGP (eBGP) peering sessions send specific routes to be 324 stored in a dedicated VRF table. The uRPF process queries the VRF 325 table (instead of the FIB) for source address validation. A VRF 326 table can be dedicated per eBGP peer and used for uRPF for only that 327 peer, resulting in strict mode operation. For implementing loose 328 uRPF on an interface, the corresponding VRF table would be global, 329 i.e., contains the same routes as in the FIB. 331 3. SAV using Enhanced Feasible-Path uRPF 333 3.1. Description of the Method 335 Enhanced feasible-path uRPF (EFP-uRPF) method adds greater 336 operational robustness and efficacy to existing uRPF methods 337 discussed in Section 2. That is because it avoids dropping 338 legitimate data packets and avoids compromising directionality. The 339 method is based on the principle that if BGP updates for multiple 340 prefixes with the same origin AS were received on different 341 interfaces (at border routers), then incoming data packets with 342 source addresses in any of those prefixes should be accepted on any 343 of those interfaces. The EFP-uRPF method can be best explained with 344 an example as follows: 346 Let us say, a border router of ISP-A has in its Adj-RIBs-In [RFC4271] 347 the set of prefixes {Q1, Q2, Q3} each of which has AS-x as its origin 348 and AS-x is in ISP-A's customer cone. In this set, the border router 349 received the route for prefix Q1 over a customer facing interface, 350 while it learned the routes for prefixes Q2 and Q3 from a lateral 351 peer and an upstream transit provider, respectively. In this example 352 scenario, the enhanced feasible-path uRPF method requires Q1, Q2, and 353 Q3 be included in the RPF list for the customer interface under 354 consideration. 356 Thus, the enhanced feasible-path uRPF (EFP-uRPF) method gathers 357 feasible paths for customer interfaces in a more precise way (as 358 compared to feasible-path uRPF) so that all legitimate packets are 359 accepted while the directionality property is not compromised. 361 The above described EFP-uRPF method is recommended to be applied on 362 customer interfaces. It can be extended to create the RPF lists for 363 lateral peer interfaces also. That is, the EFP-uRPF method can be 364 applied (and loose uRPF avoided) on lateral peer interfaces. That 365 will help avoid compromise of directionality for lateral peer 366 interfaces (which is inevitable with loose uRPF; see Section 2.4). 368 Looking back at Scenarios 1 and 2 (Figure 1 and Figure 2), the 369 enhanced feasible-path uRPF (EFP-uRPF) method works better than the 370 other uRPF methods. Scenario 3 (Figure 3) further illustrates the 371 enhanced feasible-path uRPF method with a more concrete example. In 372 this scenario, the focus is on operation of the feasible-path uRPF at 373 ISP4 (AS4). ISP4 learns a route for prefix P1 via a customer-to- 374 provider (C2P) interface from customer ISP2 (AS2). This route for P1 375 has origin AS1. ISP4 also learns a route for P2 via another C2P 376 interface from customer ISP3 (AS3). Additionally, AS4 learns a route 377 for P3 via a lateral peer-to-peer (p2p) interface from ISP5 (AS5). 378 Routes for all three prefixes have the same origin AS (i.e., AS1). 379 Using the enhanced feasible-path uRPF scheme, given the commonality 380 of the origin AS across the routes for P1, P2 and P3, AS4 includes 381 all of these prefixes in the RPF list for the customer interfaces 382 (from AS2 and AS3). 384 +----------+ P3[AS5 AS1] +------------+ 385 | AS4(ISP4)|<---------------| AS5(ISP5) | 386 +----------+ (p2p) +------------+ 387 /\ /\ /\ 388 / \ / 389 P1[AS2 AS1]/ \P2[AS3 AS1] / 390 (C2P)/ \(C2P) / 391 / \ / 392 +----------+ +----------+ / 393 | AS2(ISP2)| | AS3(ISP3)| / 394 +----------+ +----------+ / 395 /\ /\ / 396 \ / / 397 P1[AS1]\ /P2[AS1] /P3[AS1] 398 (C2P)\ /(C2P) /(C2P) 399 \ / / 400 +----------------+ / 401 | AS1(customer) |/ 402 +----------------+ 403 P1, P2, P3 (prefixes originated) 405 Consider that data packets (sourced from AS1) 406 may be received at AS4 with source address 407 in P1, P2 or P3 via any of the neighbors (AS2, AS3, AS5): 408 * Feasible-path uRPF fails 409 * Loose uRPF works (but not desirable) 410 * Enhanced Feasible-path uRPF works best 412 Figure 3: Scenario 3 for illustration of efficacy of uRPF schemes. 414 3.1.1. Algorithm A: Enhanced Feasible-Path uRPF 416 The underlying algorithm in the solution method described above 417 (Section 3.1) can be specified as follows (to be implemented in a 418 transit AS): 420 1. Create the set of unique origin ASes considering only the routes 421 in the Adj-RIBs-In of customer interfaces. Call it Set A = {AS1, 422 AS2, ..., ASn}. 424 2. Considering all routes in Adj-RIBs-In for all interfaces 425 (customer, lateral peer, and transit provider), form the set of 426 unique prefixes that have a common origin AS1. Call it Set X1. 428 3. Include set X1 in Reverse Path Filter (RPF) list on all customer 429 interfaces on which one or more of the prefixes in set X1 were 430 received. 432 4. Repeat Steps 2 and 3 for each of the remaining ASes in Set A 433 (i.e., for ASi, where i = 2, ..., n). 435 The above algorithm can be extended to apply EFP-uRPF method to 436 lateral peer interfaces also. However, it is left up to the operator 437 to decide whether they should apply EFP-uRPF or loose uRPF method on 438 lateral peer interfaces. The loose uRPF method is recommended to be 439 applied on transit provider interfaces. 441 3.2. Operational Recommendations 443 The following operational recommendations will make the operation of 444 the enhanced feasible-path uRPF robust: 446 For multi-homed stub AS: 448 o A multi-homed stub AS should announce at least one of the prefixes 449 it originates to each of its transit provider ASes. (It is 450 understood that a single-homed stub AS would announce all prefixes 451 it originates to its sole transit provider AS.) 453 For non-stub AS: 455 o A non-stub AS should also announce at least one of the prefixes it 456 originates to each of its transit provider ASes. 458 o Additionally, from the routes it has learned from customers, a 459 non-stub AS SHOULD announce at least one route per origin AS to 460 each of its transit provider ASes. 462 3.3. A Challenging Scenario 464 It should be observed that in the absence of ASes adhering to above 465 recommendations, the following example scenario may be constructed 466 which poses a challenge for the enhanced feasible-path uRPF (as well 467 as for traditional feasible-path uRPF). In the scenario illustrated 468 in Figure 4, since routes for neither P1 nor P2 are propagated on the 469 AS2-AS4 interface (due to the presence of NO_EXPORT Community), the 470 enhanced feasible-path uRPF at AS4 will reject data packets received 471 on that interface with source addresses in P1 or P2. (For a little 472 more complex example scenario, see slide #10 in [sriram-urpf].) 474 +----------+ 475 | AS4(ISP4)| 476 +----------+ 477 /\ /\ 478 / \ P1[AS3 AS1] 479 P1 and P2 not / \ P2[AS3 AS1] 480 propagated / \ (C2P) 481 (C2P) / \ 482 +----------+ +----------+ 483 | AS2(ISP2)| | AS3(ISP3)| 484 +----------+ +----------+ 485 /\ /\ 486 \ / P1[AS1] 487 P1[AS1] NO_EXPORT \ / P2[AS1] 488 P2[AS1] NO_EXPORT \ / (C2P) 489 (C2P) \ / 490 +----------------+ 491 | AS1(customer) | 492 +----------------+ 493 P1, P2 (prefixes originated) 495 Consider that data packets (sourced from AS1) 496 may be received at AS4 with source address 497 in P1 or P2 via AS2: 498 * Feasible-path uRPF fails 499 * Loose uRPF works (but not desirable) 500 * Enhanced Feasible-path uRPF with Algorithm A fails 501 * Enhanced Feasible-path uRPF with Algorithm B works best 503 Figure 4: Illustration of a challenging scenario. 505 3.4. Algorithm B: Enhanced Feasible-Path uRPF with Additional 506 Flexibility Across Customer Cone 508 Adding further flexibility to the enhanced feasible-path uRPF method 509 can help address the potential limitation identified above using the 510 scenario in Figure 4 (Section 3.3). In the following, "route" refers 511 to a route currently existing in the Adj-RIB-in. Including the 512 additional degree of flexibility, the modified algorithm called 513 Algorithm B (implemented in a transit AS) can be described as 514 follows: 516 1. Create the set of all directly-connected customer interfaces. 517 Call it Set I = {I1, I2, ..., Ik}. 519 2. Create the set of all unique prefixes for which routes exist in 520 Adj-RIBs-In for the interfaces in Set I. Call it Set P = {P1, 521 P2, ..., Pm}. 523 3. Create the set of all unique origin ASes seen in the routes that 524 exist in Adj-RIBs-In for the interfaces in Set I. Call it Set A 525 = {AS1, AS2, ..., ASn}. 527 4. Create the set of all unique prefixes for which routes exist in 528 Adj-RIBs-In of all lateral peer and transit provider interfaces 529 such that each of the routes has its origin AS belonging in Set 530 A. Call it Set Q = {Q1, Q2, ..., Qj}. 532 5. Then, Set Z = Union(P,Q) is the RPF list that is applied for 533 every customer interface in Set I. 535 When Algorithm B (which is more flexible than Algorithm A) is 536 employed on customer interfaces, the type of limitation identified in 537 Figure 4 (Section 3.3) is overcome and the method works. The 538 directionality property is minimally compromised, but still the 539 proposed EFP-uRPF method with Algorithm B is a much better choice 540 (for the scenario under consideration) than applying the loose uRPF 541 method which is oblivious to directionality. 543 So, applying EFP-uRPF method with Algorithm B is recommended on 544 customer interfaces for the challenging scenarios such as those 545 described in Section 3.3. 547 3.5. Augmenting RPF Lists with ROA and IRR Data 549 It is worth emphasizing that an indirect part of the proposal in this 550 document is that RPF filters may be augmented from secondary sources. 551 Hence, the construction of RPF lists using a method proposed in this 552 document (Algorithm A or B) can be augmented with data from Route 553 Origin Authorization (ROA) [RFC6482] as well as Internet Routing 554 Registry (IRR) data. Special care should be exercised when using IRR 555 data because it not always accurate or trusted. In the EFP-uRPF 556 method with Algorithm A (see Section 3.1.1), if a ROA includes prefix 557 Pi and ASj, then augment with Pi the RPF list of each customer 558 interface on which at least one route with origin ASj was received. 559 In the EFP-uRPF method with Algorithm B, if ASj belongs in set A (see 560 Step #3 Section 3.4) and if a ROA includes prefix Pi and ASj, then 561 augment with Pi the RPF list Z in Step 5 of Algorithm B. Similar 562 procedures can be followed with reliable IRR data as well. This will 563 help make the RPF lists more robust about source addresses that may 564 be legitimately used by customers of the ISP. 566 3.6. Implementation and Operations Considerations 568 3.6.1. Impact on FIB Memory Size Requirement 570 The existing RPF checks in edge routers take advantage of existing 571 line card implementations to perform the RPF functions. For 572 implementation of the enhanced feasible-path uRPF, the general 573 necessary feature would be to extend the line cards to take arbitrary 574 RPF lists that are not necessarily the same as the existing FIB 575 contents. In the algorithms (Section 3.1.1 and Section 3.4) 576 described here, the RPF lists are constructed by applying a set of 577 rules to all received BGP routes (not just those selected as best 578 path and installed in the FIB). The concept of uRPF querying an RPF 579 list (instead of the FIB) is similar to uRPF querying a VRF table 580 (see (Section 2.5). 582 The techniques described in this document require that there should 583 be additional memory (i.e., ternary content addressable memory 584 (TCAM)) available to store the RPF lists in line cards. For an ISP's 585 AS, the RPF list size for each line card will roughly equal the total 586 number of originated prefixes from ASes in its customer cone 587 (assuming Algorithm B in Section 3.4 is used). (Note: EFP-uRPF with 588 Algorithm A (see Section 3.1.1) requires much less memory than EFP- 589 uRPF with Algorithm B.) 591 The following table shows the measured customer cone sizes in number 592 of prefixes originated (from all ASes in the customer cone) for 593 various types of ISPs [sriram-ripe63]: 595 +---------------------------------+---------------------------------+ 596 | Type of ISP | Measured Customer Cone Size in | 597 | | # Prefixes (in turn this is an | 598 | | estimate for RPF list size on | 599 | | the line card) | 600 +---------------------------------+---------------------------------+ 601 | Very Large Global ISP #1 | 32393 | 602 | ------------------------------- | ------------------------------- | 603 | Very Large Global ISP #2 | 29528 | 604 | ------------------------------- | ------------------------------- | 605 | Large Global ISP | 20038 | 606 | ------------------------------- | ------------------------------- | 607 | Mid-size Global ISP | 8661 | 608 | ------------------------------- | ------------------------------- | 609 | Regional ISP (in Asia) | 1101 | 610 +---------------------------------+---------------------------------+ 612 Table 1: Customer cone sizes (# prefixes) for various types of ISPs. 614 For some super large global ISPs that are at the core of the 615 Internet, the customer cone size (# prefixes) can be as high as a few 616 hundred thousand [CAIDA]. But uRPF is most effective when deployed 617 at ASes at the edges of the Internet where the customer cone sizes 618 are smaller as shown in Table 1. 620 A very large global ISP's router line card is likely to have a FIB 621 size large enough to accommodate 2 million routes [Cisco1]. 622 Similarly, the line cards in routers corresponding to a large global 623 ISP, a mid-size global ISP, and a regional ISP are likely to have FIB 624 sizes large enough to accommodate about 1 million, 0.5 million, and 625 100K routes, respectively [Cisco2]. Comparing these FIB size numbers 626 with the corresponding RPF list size numbers in Table 1, it can be 627 surmised that the conservatively estimated RPF list size is only a 628 small fraction of the anticipated FIB memory size under relevant ISP 629 scenarios. What is meant here by relevant ISP scenarios is that only 630 smaller ISPs (and possibly some mid-size and regional ISPs) are 631 expected to implement the proposed EFP-uRPF method since it is most 632 effective closer to the edges of the Internet. 634 3.6.2. Coping with BGP's Transient Behavior 636 BGP routing announcements can exhibit transient behavior. Routes may 637 be withdrawn temporarily and then re-announced due to transient 638 conditions such as BGP session reset or link failure-recovery. To 639 cope with this, hysteresis should be introduced in the maintenance of 640 the RPF lists. Deleting entries from the RPF lists SHOULD be delayed 641 by a pre-determined amount (the value based on operational 642 experience) when responding to route withdrawals. This should help 643 suppress the effects due to the transients in BGP. 645 3.7. Summary of Recommendations 647 Depending on the scenario, an ISP or enterprise AS operator should 648 follow one of the following recommendations concerning uRPF/SAV: 650 1. For directly connected networks, i.e., subnets directly connected 651 to the AS, the AS under consideration SHOULD perform ACL-based 652 source address validation (SAV). 654 2. For a directly connected single-homed stub AS (customer), the AS 655 under consideration SHOULD perform SAV based on the strict uRPF 656 method. 658 3. For all other scenarios: 660 * The enhanced feasible-path uRPF (EFP-uRPF) method with 661 Algorithm B (see Section 3.4) SHOULD be applied on customer 662 interfaces. 664 * Loose uRPF method SHOULD be applied on lateral peer and 665 transit provider interfaces. 667 It is also recommended that prefixes from registered ROAs and IRR 668 route objects that include ASes in an ISP's customer cone SHOULD be 669 used to augment the pertaining RPF lists (see Section 3.5 for 670 details). 672 3.7.1. Applicability of the enhanced feasible-path uRPF (EFP-uRPF) 673 method with Algorithm A 675 EFP-uRPF method with Algorithm A is not mentioned in the above set of 676 recommendations. It is an alternative to EFP-uRPF with Algorithm B 677 and can be used in limited circumstances. The EFP-uRPF method with 678 Algorithm A is expected to work fine if an ISP deploying it has only 679 multi-homed stub customers. It is trivially equivalent to strict 680 uRPF if an ISP deploys it for a single-homed stub customer. More 681 generally, it is also expected to work fine when there is absence of 682 limitations such as those described in Section 3.3. However, caution 683 is required for use of EFP-uRPF with Algorithm A because even if the 684 limitations are not expected at the time of deployment, the 685 vulnerability to change in conditions exists. It may be difficult 686 for an ISP to know or track the extent of use of NO_EXPORT (see 687 Section 3.3) on routes within its customer cone. If an ISP decides 688 to use EFP-uRPF with Algorithm A, it should make its direct customers 689 aware of the operational recommendations in Section 3.2. This means 690 that the ISP notifies direct customers that at least one prefix 691 originated by each AS in the direct customer's customer cone must 692 propagate to the ISP. 694 On a lateral peer interface, an ISP may choose to apply the EFP-uRPF 695 method with Algorithm A (with appropriate modification of the 696 algorithm). This is because stricter forms of uRPF (than the loose 697 uRPF) may be considered applicable by some ISPs on interfaces with 698 lateral peers. 700 4. Security Considerations 702 The security considerations in BCP 38 [RFC2827] and BCP 84 [RFC3704] 703 apply for this document as well. In addition, if considering using 704 EFP-uRPF method with Algorithm A, an ISP or AS operator should be 705 aware of the applicability considerations and potential 706 vulnerabilities discussed in Section 3.7.1. 708 In augmenting RPF lists with ROA (and possibly reliable IRR) 709 information (see Section 3.5), a trade-off is made in favor of 710 reducing false positives (regarding invalid detection in SAV) at the 711 expense of a slight other risk. The other risk being a malicious 712 actor at another AS in the neighborhood within the customer cone 713 might take advantage (of the augmented prefix) to some extent. This 714 risk also exists even with normal announced prefixes (i.e., without 715 ROA augmentation) for any uRPF method other than the strict. 716 However, the risk is mitigated if the transit provider of the other 717 AS in question is performing SAV. 719 Though not within the scope of this document, security hardening of 720 routers and other supporting systems (e.g., Resource PKI (RPKI) and 721 ROA management systems) against compromise is extremely important. 722 The compromise of those systems can affect the operation and 723 performance of the SAV methods described in this document. 725 5. IANA Considerations 727 This document does not request new capabilities or attributes. It 728 does not create any new IANA registries. 730 6. Acknowledgements 732 The authors would like to thank Sandy Murphy, Alvaro Retana, Job 733 Snijders, Marco Marzetti, Marco d'Itri, Nick Hilliard, Gert Doering, 734 Fred Baker, Igor Gashinsky, Igor Lubashev, Andrei Robachevsky, Barry 735 Greene, Amir Herzberg, Ruediger Volk, Jared Mauch, Oliver Borchert, 736 Mehmet Adalier, and Joel Jaeggli for comments and suggestions. The 737 comments and suggestions received from the IESG reviewers are also 738 much appreciated. 740 7. References 742 7.1. Normative References 744 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 745 Requirement Levels", BCP 14, RFC 2119, 746 DOI 10.17487/RFC2119, March 1997, 747 . 749 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 750 Defeating Denial of Service Attacks which employ IP Source 751 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 752 May 2000, . 754 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 755 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 756 2004, . 758 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 759 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 760 DOI 10.17487/RFC4271, January 2006, 761 . 763 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 764 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 765 May 2017, . 767 7.2. Informative References 769 [CAIDA] "Information for AS 174 (COGENT-174)", CAIDA Spoofer 770 Project , . 772 [Cisco1] "Internet Routing Table Growth Causes ROUTING-FIB- 773 4-RSRC_LOW Message on Trident-Based Line Cards", Cisco 774 Trouble-shooting Tech-notes , January 2014, 775 . 779 [Cisco2] "Cisco Nexus 7000 Series NX-OS Unicast Routing 780 Configuration Guide, Release 5.x (Chapter 15: Managing the 781 Unicast RIB and FIB)", Cisco Configuration Guides , March 782 2018, . 787 [Firmin] Firmin, F., "The Evolved Packet Core", 3GPP The Mobile 788 Broadband Standard , . 791 [ISOC] Vixie (Ed.), P., "Addressing the challenge of IP 792 spoofing", ISOC report , September 2015, 793 . 796 [Juniper] "Creating Unique VPN Routes Using VRF Tables", Juniper 797 Networks TechLibrary , March 2019, 798 . 802 [Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and 803 kc. claffy, "AS Relationships, Customer Cones, and 804 Validation", In Proceedings of the 2013 ACM Internet 805 Measurement Conference (IMC), DOI 10.1145/2504730.2504735, 806 October 2013, 807 . 809 [RFC4036] Sawyer, W., "Management Information Base for Data Over 810 Cable Service Interface Specification (DOCSIS) Cable Modem 811 Termination Systems for Subscriber Management", RFC 4036, 812 DOI 10.17487/RFC4036, April 2005, 813 . 815 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 816 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 817 2006, . 819 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 820 Origin Authorizations (ROAs)", RFC 6482, 821 DOI 10.17487/RFC6482, February 2012, 822 . 824 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 825 Austein, "BGP Prefix Origin Validation", RFC 6811, 826 DOI 10.17487/RFC6811, January 2013, 827 . 829 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 830 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 831 February 2015, . 833 [SPAR-v4] "IANA IPv4 Special-Purpose Address Registry", IANA , 834 . 837 [SPAR-v6] "IANA IPv6 Special-Purpose Address Registry", IANA , 838 . 841 [sriram-ripe63] 842 Sriram, K. and R. Bush, "Estimating CPU Cost of BGPSEC on 843 a Router", Presented at RIPE-63; also, at IETF-83 SIDR WG 844 Meeting, March 2012, 845 . 848 [sriram-urpf] 849 Sriram et al., K., "Enhanced Feasible-Path Unicast Reverse 850 Path Filtering", Presented at the OPSEC WG Meeting, 851 IETF-101 London , March 2018, 852 . 855 Authors' Addresses 857 Kotikalapudi Sriram 858 USA National Institute of Standards and Technology 859 100 Bureau Drive 860 Gaithersburg MD 20899 861 USA 863 Email: ksriram@nist.gov 864 Doug Montgomery 865 USA National Institute of Standards and Technology 866 100 Bureau Drive 867 Gaithersburg MD 20899 868 USA 870 Email: dougm@nist.gov 872 Jeffrey Haas 873 Juniper Networks, Inc. 874 1133 Innovation Way 875 Sunnyvale CA 94089 876 USA 878 Email: jhaas@juniper.net