idnits 2.17.1 draft-sriram-sidrops-drop-invalid-policy-06.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 115: '...ix. DISR policy MUST apply the follow...' RFC 2119 keyword, line 167: '...ock, an operator MUST ensure that all ...' RFC 2119 keyword, line 174: '...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 (November 24, 2020) is 1220 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 230, 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: May 28, 2021 USA NIST 6 November 24, 2020 8 Origin Validation Policy Considerations for Dropping Invalid Routes 9 draft-sriram-sidrops-drop-invalid-policy-06 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 May 28, 2021. 42 Copyright Notice 44 Copyright (c) 2020 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 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Drop Invalid if Still Routable (DISR) Policy . . . . . . . . 3 61 2.1. Motivation for the DISR Policy . . . . . . . . . . . . . 3 62 3. Algorithm for Implementation of DISR Policy . . . . . . . . . 4 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 5. Normative References . . . . . . . . . . . . . . . . . . . . 5 65 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 Deployment of Resource Public Key Infrastructure (RPKI) [RFC6481] and 71 Route Origin Authorizations (ROAs) [RFC6482] is expected to occur 72 gradually over several or many years. ROA-based BGP Origin 73 Validation (OV) process and the OV states are defined in [RFC6811]. 74 During the incremental deployment period, network operators would 75 wish to have a meaningful policy for dropping Invalid routes. Their 76 goal is to balance (A) dropping Invalid routes so hijacked routes can 77 be eliminated, versus (B) tolerance for missing or erroneously 78 created ROAs for customer prefixes. This document considers a Drop 79 Invalid if Still Routable (DISR) policy that is based on these 80 considerations. The key principle of DISR policy is that an Invalid 81 route can be dropped if a Valid or NotFound route exists for a 82 subsuming less specific prefix. 84 The DISR policy applies in addition to (1) preferring Valid when more 85 than one route exists for the same prefix, and (2) always including 86 NotFound routes in the best path selection process. Note that for a 87 router performing OV, the existence of a NotFound route excludes the 88 possibility of an alternate Valid or Invalid route for the same 89 prefix or a subsuming less specific prefix. 91 This document also provides an algorithm for best path selection 92 policy that considers Origin Validation (OV) outcome and includes the 93 DISR policy. 95 2. Drop Invalid if Still Routable (DISR) Policy 97 When BGP origin validation (OV) [RFC6811] is performed on a BGP 98 route, there are three possible outcomes: (1) Valid, (2) Invalid, or 99 (3) NotFound. During partial/incremental deployment of RPKI and 100 ROAs, it is natural to always include Valid and NotFound routes in 101 the path selection decision process. Note that Valid and NotFound 102 are mutually exclusive, i.e., at a validating router, there cannot be 103 two routes for a prefix where one is Valid and the other is NotFound. 104 Similarly, Invalid and NotFound are also mutually exclusive. If 105 Invalid routes are always dropped from consideration, then there 106 would be no tolerance for missing or erroneously created ROAs for 107 customer prefixes. Then the question arises whether the following 108 policy should be considered: Drop an Invalid route only if another 109 Valid or NotFound route exists for a subsuming less specific prefix? 110 This policy is called Drop Invalid if Still Routable (DISR). 112 The existence of an AS0 ROA for a prefix means that the prefix or any 113 more specific prefix subsumed in it are forbidden from routing except 114 when there exists a different ROA with a normal ASN for the prefix or 115 the more specific prefix. DISR policy MUST apply the following 116 exception: If a route is Invalid due to an AS0 ROA, then always drop 117 the route. 119 Any routes for 0.0.0.0/0 (IPv4) or ::/0 (IPv6) in the routing table 120 must be excluded from consideration in the DISR policy. (Author's 121 note: Think this through with help from the WG.) 123 2.1. Motivation for the DISR Policy 125 Consider these scenarios: 127 Scenario 1: A transit ISP A (AS A) created a ROA for a /22 prefix 128 they announce. They also announce a /24 prefix (subsumed in the /22) 129 that is owned by directly-connected customer X (has no AS). But ISP 130 A neglected to create a ROA for X's /24 prefix. Clearly, the 131 announcement of X's /24 will be Invalid. ISP A happens to propagate 132 to neighbors the /22 and the /24. 134 Scenario 2: Customer X (AS X) announces a /22 prefix only to transit 135 ISP A and a /24 prefix (subsumed in the /22) only to transit ISP B. 136 X is attempting to do traffic engineering (TE). X created a ROA for 137 the /22 but neglected to have ROA coverage for the /24. Clearly, X's 138 announcement of the /24 will be Invalid. ISP B does not participate 139 in OV and propagates the Invalid route to its neighbors. 141 In each of the above scenarios, DISR policy (applied at routers 142 elsewhere in the Internet) ensures that traffic for the more specific 143 (/24) still reaches the correct destination, i.e., customer X (albeit 144 possibly via a suboptimal / non-TE path). Any actual hijacks of the 145 /24 prefix would be dropped at all eBGP routers that employ the DISR 146 policy. Please see [sriram-disr] for analysis of several more 147 scenarios. 149 Measurements show that if OV were performed, there are 10,417 Invalid 150 routes in the global Internet based on analysis of Routeviews/RPKI/ 151 ROA data from February 2018. Of these, 6846 routes are Invalid due 152 to exceeding the maxlength. 6027 of the 6846 Invalid prefixes are 153 seen to be routable via alternate Valid or NotFound routes for either 154 the same prefix (as in the Invalid route) or a subsuming less 155 specific prefix. Again, 5987 of the 6027 are routes for which the 156 corresponding Valid or NotFound routes (with the same or subsuming 157 less specific prefix) have the exact same origin AS as in the Invalid 158 route in question. These measurements show that Scenarios 1 and 2 159 described above do occur in significant numbers currently. So, the 160 data lends support to the efficacy of the DISR policy in terms of 161 delivering the data traffic to the right destination though not 162 necessarily via the optimal/TE path. Please see [sriram-disr] for 163 more detailed results from the Routeviews/RPKI/ROA data measurement 164 study. 166 The following is recommended in BCP 185 [RFC7115]: "Before issuing a 167 ROA for a super-block, an operator MUST ensure that all sub- 168 allocations from that block that are announced by other ASes, e.g., 169 customers, have correct ROAs in the RPKI." However, as seen by the 170 above measurement data, there are lapses in following this 171 recommendation. 173 Network operators who do not wish to drop Invalid routes outright in 174 partial deployment SHOULD consider employing the DISR policy. It 175 helps eliminate actual prefix hijacks, while incentivizing creation 176 of required ROAs and the adherence to the above recommendation from 177 BCP 185. The stick used here is the possibility of data traveling 178 via a suboptimal path, while the more aggressive stick of dropping 179 all Invalid routes is held in abeyance. 181 3. Algorithm for Implementation of DISR Policy 183 An algorithm for implementation of the DISR policy is as follows. 185 Perform the following steps when a route is received: 187 1. Perform BGP Origin Validation (OV) [RFC6811] on the routes in the 188 Adj-RIB-ins. 190 2. Apply best path decision process including the results of OV. 191 Include NotFound routes in the decision process. When there is a 192 choice, prefer Valid over Invalid routes. 194 3. Store the selected routes in the Loc-RIB. 196 4. Apply the DISR policy. Process routes in the order of least 197 specific to most specific. If a selected route in the Loc-RIB is 198 Valid/NotFound, then add the route to FIB and Adj-RIB-outs; Else, 199 if Invalid, then add the route to FIB and Adj-RIB-outs only if 200 there is no existing Valid/NotFound route in the Loc-RIB for a 201 subsuming Less Specific prefix. 203 Additional steps in the algorithm that are performed in reaction to 204 addition/withdrawal of routes that influence DISR policy decisions 205 and due to changes in RPKI: 207 a. When a Valid/NotFound route is added to Loc-RIB, check if there 208 are any more specific prefixes in the FIB and Adj-RIB-Outs 209 subsumed by the route prefix; If such more specific prefix route 210 is Invalid, then remove it from the FIB and Adj-RIB-Outs. 212 b. When a Valid/NotFound route is withdrawn from Loc-RIB, check if 213 there are any more specifics prefixes in the Loc-RIB subsumed by 214 the route prefix; If such more specific prefix route is Invalid, 215 then add the route to FIB and Adj-RIB-outs. 217 c. When the router is notified of RPKI state change, then list all 218 the prefixes effected by it. Rerun route selection decision and 219 DISR policy for those prefixes. 221 4. Security Considerations 223 This document addresses some aspects of best common practices for 224 origin validation and related BGP policy. The security 225 considerations provided in RFC 6811 [RFC6811] and BCP 185 [RFC7115] 226 also apply here. 228 5. Normative References 230 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 231 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 232 DOI 10.17487/RFC4271, January 2006, 233 . 235 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 236 Resource Certificate Repository Structure", RFC 6481, 237 DOI 10.17487/RFC6481, February 2012, 238 . 240 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 241 Origin Authorizations (ROAs)", RFC 6482, 242 DOI 10.17487/RFC6482, February 2012, 243 . 245 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 246 Austein, "BGP Prefix Origin Validation", RFC 6811, 247 DOI 10.17487/RFC6811, January 2013, 248 . 250 [RFC7115] Bush, R., "Origin Validation Operation Based on the 251 Resource Public Key Infrastructure (RPKI)", BCP 185, 252 RFC 7115, DOI 10.17487/RFC7115, January 2014, 253 . 255 [sriram-disr] 256 Sriram et al., K., "Origin Validation Policy 257 Considerations for Dropping Invalid Routes", Presented at 258 the SIDROPS WG Meeting, IETF-101, London , March 2018, 259 . 263 Acknowledgements 265 The authors wish to thank Sebastian Spies, Saku Ytti, Jeffrey Haas, 266 Tim Bruijnzeels, Keyur Patel, Warren Kumari, John Scudder, and Jay 267 Borkenhagen for comments and discussion related to this work. Also, 268 thanks are due to Lilia Hannachi for her insightful analysis of 269 global RPKI and BGP data that has been helpful in this work. 271 Authors' Addresses 273 Kotikalapudi Sriram 274 USA National Institute of Standards and Technology 276 Email: ksriram@nist.gov 278 Oliver Borchert 279 USA National Institute of Standards and Technology 281 Email: oliver.borchert@nist.gov 282 Doug Montgomery 283 USA National Institute of Standards and Technology 285 Email: dougm@nist.gov