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