idnits 2.17.1 draft-sriram-sidrops-drop-invalid-policy-08.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 114: '...ix. DISR policy MUST apply the follow...' RFC 2119 keyword, line 166: '...ock, an operator MUST ensure that all ...' RFC 2119 keyword, line 173: '...rtial deployment SHOULD consider emplo...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (28 November 2021) is 851 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) == Unused Reference: 'RFC4271' is defined on line 229, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDROPS Working Group K. Sriram 3 Internet-Draft O. Borchert 4 Intended status: Best Current Practice D. Montgomery 5 Expires: 1 June 2022 USA NIST 6 28 November 2021 8 Origin Validation Policy Considerations for Dropping Invalid Routes 9 draft-sriram-sidrops-drop-invalid-policy-08 11 Abstract 13 Deployment of Resource Public Key Infrastructure (RPKI) and Route 14 Origin Authorizations (ROAs) is expected to occur gradually over 15 several or many years. During the incremental deployment period, 16 network operators would wish to have a meaningful policy for dropping 17 Invalid routes. Their goal is to balance (A) dropping Invalid routes 18 so hijacked routes can be eliminated, versus (B) tolerance for 19 missing or erroneously created ROAs for customer prefixes. This 20 document considers a Drop Invalid if Still Routable (DISR) policy 21 that is based on these considerations. The key principle of DISR 22 policy is that an Invalid route can be dropped if a Valid or NotFound 23 route exists for a subsuming less specific prefix. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 1 June 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Drop Invalid if Still Routable (DISR) Policy . . . . . . . . 3 60 2.1. Motivation for the DISR Policy . . . . . . . . . . . . . 3 61 3. Algorithm for Implementation of DISR Policy . . . . . . . . . 4 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 5. Normative References . . . . . . . . . . . . . . . . . . . . 5 64 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 Deployment of Resource Public Key Infrastructure (RPKI) [RFC6481] and 70 Route Origin Authorizations (ROAs) [RFC6482] is expected to occur 71 gradually over several or many years. ROA-based BGP Origin 72 Validation (OV) process and the OV states are defined in [RFC6811]. 73 During the incremental deployment period, network operators would 74 wish to have a meaningful policy for dropping Invalid routes. Their 75 goal is to balance (A) dropping Invalid routes so hijacked routes can 76 be eliminated, versus (B) tolerance for missing or erroneously 77 created ROAs for customer prefixes. This document considers a Drop 78 Invalid if Still Routable (DISR) policy that is based on these 79 considerations. The key principle of DISR policy is that an Invalid 80 route can be dropped if a Valid or NotFound route exists for a 81 subsuming less specific prefix. 83 The DISR policy applies in addition to (1) preferring Valid when more 84 than one route exists for the same prefix, and (2) always including 85 NotFound routes in the best path selection process. Note that for a 86 router performing OV, the existence of a NotFound route excludes the 87 possibility of an alternate Valid or Invalid route for the same 88 prefix or a subsuming less specific prefix. 90 This document also provides an algorithm for best path selection 91 policy that considers Origin Validation (OV) outcome and includes the 92 DISR policy. 94 2. Drop Invalid if Still Routable (DISR) Policy 96 When BGP origin validation (OV) [RFC6811] is performed on a BGP 97 route, there are three possible outcomes: (1) Valid, (2) Invalid, or 98 (3) NotFound. During partial/incremental deployment of RPKI and 99 ROAs, it is natural to always include Valid and NotFound routes in 100 the path selection decision process. Note that Valid and NotFound 101 are mutually exclusive, i.e., at a validating router, there cannot be 102 two routes for a prefix where one is Valid and the other is NotFound. 103 Similarly, Invalid and NotFound are also mutually exclusive. If 104 Invalid routes are always dropped from consideration, then there 105 would be no tolerance for missing or erroneously created ROAs for 106 customer prefixes. Then the question arises whether the following 107 policy should be considered: Drop an Invalid route only if another 108 Valid or NotFound route exists for a subsuming less specific prefix? 109 This policy is called Drop Invalid if Still Routable (DISR). 111 The existence of an AS0 ROA for a prefix means that the prefix or any 112 more specific prefix subsumed in it are forbidden from routing except 113 when there exists a different ROA with a normal ASN for the prefix or 114 the more specific prefix. DISR policy MUST apply the following 115 exception: If a route is Invalid due to an AS0 ROA, then always drop 116 the route. 118 Any routes for 0.0.0.0/0 (IPv4) or ::/0 (IPv6) in the routing table 119 must be excluded from consideration in the DISR policy. (Author's 120 note: Think this through with help from the WG.) 122 2.1. Motivation for the DISR Policy 124 Consider these scenarios: 126 Scenario 1: A transit ISP A (AS A) created a ROA for a /22 prefix 127 they announce. They also announce a /24 prefix (subsumed in the /22) 128 that is owned by directly-connected customer X (has no AS). But ISP 129 A neglected to create a ROA for X's /24 prefix. Clearly, the 130 announcement of X's /24 will be Invalid. ISP A happens to propagate 131 to neighbors the /22 and the /24. 133 Scenario 2: Customer X (AS X) announces a /22 prefix only to transit 134 ISP A and a /24 prefix (subsumed in the /22) only to transit ISP B. 135 X is attempting to do traffic engineering (TE). X created a ROA for 136 the /22 but neglected to have ROA coverage for the /24. Clearly, X's 137 announcement of the /24 will be Invalid. ISP B does not participate 138 in OV and propagates the Invalid route to its neighbors. 140 In each of the above scenarios, DISR policy (applied at routers 141 elsewhere in the Internet) ensures that traffic for the more specific 142 (/24) still reaches the correct destination, i.e., customer X (albeit 143 possibly via a suboptimal / non-TE path). Any actual hijacks of the 144 /24 prefix would be dropped at all eBGP routers that employ the DISR 145 policy. Please see [sriram-disr] for analysis of several more 146 scenarios. 148 Measurements show that if OV were performed, there are 10,417 Invalid 149 routes in the global Internet based on analysis of Routeviews/RPKI/ 150 ROA data from February 2018. Of these, 6846 routes are Invalid due 151 to exceeding the maxlength. 6027 of the 6846 Invalid prefixes are 152 seen to be routable via alternate Valid or NotFound routes for either 153 the same prefix (as in the Invalid route) or a subsuming less 154 specific prefix. Again, 5987 of the 6027 are routes for which the 155 corresponding Valid or NotFound routes (with the same or subsuming 156 less specific prefix) have the exact same origin AS as in the Invalid 157 route in question. These measurements show that Scenarios 1 and 2 158 described above do occur in significant numbers currently. So, the 159 data lends support to the efficacy of the DISR policy in terms of 160 delivering the data traffic to the right destination though not 161 necessarily via the optimal/TE path. Please see [sriram-disr] for 162 more detailed results from the Routeviews/RPKI/ROA data measurement 163 study. 165 The following is recommended in BCP 185 [RFC7115]: "Before issuing a 166 ROA for a super-block, an operator MUST ensure that all sub- 167 allocations from that block that are announced by other ASes, e.g., 168 customers, have correct ROAs in the RPKI." However, as seen by the 169 above measurement data, there are lapses in following this 170 recommendation. 172 Network operators who do not wish to drop Invalid routes outright in 173 partial deployment SHOULD consider employing the DISR policy. It 174 helps eliminate actual prefix hijacks, while incentivizing creation 175 of required ROAs and the adherence to the above recommendation from 176 BCP 185. The stick used here is the possibility of data traveling 177 via a suboptimal path, while the more aggressive stick of dropping 178 all Invalid routes is held in abeyance. 180 3. Algorithm for Implementation of DISR Policy 182 An algorithm for implementation of the DISR policy is as follows. 184 Perform the following steps when a route is received: 186 1. Perform BGP Origin Validation (OV) [RFC6811] on the routes in the 187 Adj-RIB-ins. 189 2. Apply best path decision process including the results of OV. 190 Include NotFound routes in the decision process. When there is a 191 choice, prefer Valid over Invalid routes. 193 3. Store the selected routes in the Loc-RIB. 195 4. Apply the DISR policy. Process routes in the order of least 196 specific to most specific. If a selected route in the Loc-RIB is 197 Valid/NotFound, then add the route to FIB and Adj-RIB-outs; Else, 198 if Invalid, then add the route to FIB and Adj-RIB-outs only if 199 there is no existing Valid/NotFound route in the Loc-RIB for a 200 subsuming Less Specific prefix. 202 Additional steps in the algorithm that are performed in reaction to 203 addition/withdrawal of routes that influence DISR policy decisions 204 and due to changes in RPKI: 206 a. When a Valid/NotFound route is added to Loc-RIB, check if there 207 are any more specific prefixes in the FIB and Adj-RIB-Outs 208 subsumed by the route prefix; If such more specific prefix route 209 is Invalid, then remove it from the FIB and Adj-RIB-Outs. 211 b. When a Valid/NotFound route is withdrawn from Loc-RIB, check if 212 there are any more specifics prefixes in the Loc-RIB subsumed by 213 the route prefix; If such more specific prefix route is Invalid, 214 then add the route to FIB and Adj-RIB-outs. 216 c. When the router is notified of RPKI state change, then list all 217 the prefixes effected by it. Rerun route selection decision and 218 DISR policy for those prefixes. 220 4. Security Considerations 222 This document addresses some aspects of best common practices for 223 origin validation and related BGP policy. The security 224 considerations provided in RFC 6811 [RFC6811] and BCP 185 [RFC7115] 225 also apply here. 227 5. Normative References 229 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 230 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 231 DOI 10.17487/RFC4271, January 2006, 232 . 234 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 235 Resource Certificate Repository Structure", RFC 6481, 236 DOI 10.17487/RFC6481, February 2012, 237 . 239 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 240 Origin Authorizations (ROAs)", RFC 6482, 241 DOI 10.17487/RFC6482, February 2012, 242 . 244 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 245 Austein, "BGP Prefix Origin Validation", RFC 6811, 246 DOI 10.17487/RFC6811, January 2013, 247 . 249 [RFC7115] Bush, R., "Origin Validation Operation Based on the 250 Resource Public Key Infrastructure (RPKI)", BCP 185, 251 RFC 7115, DOI 10.17487/RFC7115, January 2014, 252 . 254 [sriram-disr] 255 Sriram et al., K., "Origin Validation Policy 256 Considerations for Dropping Invalid Routes", Presented at 257 the SIDROPS WG Meeting, IETF-101, London , March 2018, 258 . 262 Acknowledgements 264 The authors wish to thank Sebastian Spies, Saku Ytti, Jeffrey Haas, 265 Tim Bruijnzeels, Keyur Patel, Warren Kumari, John Scudder, and Jay 266 Borkenhagen for comments and discussion related to this work. Also, 267 thanks are due to Lilia Hannachi for her insightful analysis of 268 global RPKI and BGP data that has been helpful in this work. 270 Authors' Addresses 272 Kotikalapudi Sriram 273 USA National Institute of Standards and Technology 275 Email: ksriram@nist.gov 277 Oliver Borchert 278 USA National Institute of Standards and Technology 280 Email: oliver.borchert@nist.gov 281 Doug Montgomery 282 USA National Institute of Standards and Technology 284 Email: dougm@nist.gov