idnits 2.17.1 draft-sriram-sidrops-drop-invalid-policy-00.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 150: '...ock, an operator MUST ensure that all ...' RFC 2119 keyword, line 158: '... SHOULD consider employing the DISR ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2236 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: September 6, 2018 USA NIST 6 March 5, 2018 8 Origin Validation Policy Considerations for Dropping Invalid Routes 9 draft-sriram-sidrops-drop-invalid-policy-00 11 Abstract 13 During incremental deployment of RPKI and Route Origin Authorizations 14 (and possibly under some transient conditions), network operators 15 would wish to have a meaningful policy for dropping Invalid routes. 16 Their goal is to balance (A) dropping Invalid routes so hijacked 17 routes can be eliminated, versus (B) tolerance for missing or 18 erroneously created ROAs for customer prefixes. This document 19 considers a Drop Invalid if Still Routable (DISR) policy that is 20 based on these considerations. The key principle of DISR policy is 21 that an Invalid route can be dropped if a Valid or NotFound route 22 exists for a subsuming less specific prefix. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 6, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Drop Invalid if Still Routable (DISR) Policy . . . . . . . . 2 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 During incremental deployment of RPKI [RFC6481] and Route Origin 70 Authorizations [RFC6482] (and possibly under some transient 71 conditions), network operators would wish to have a meaningful policy 72 for dropping Invalid routes (see [RFC6811] for validation state 73 definitions). Their goal is to balance (A) dropping Invalid routes 74 so hijacked routes can be eliminated, versus (B) tolerance for 75 missing or erroneously created ROAs for customer prefixes. This 76 document considers a Drop Invalid if Still Routable (DISR) policy 77 that is based on these considerations. The key principle of DISR 78 policy is that an Invalid route can be dropped if a Valid or NotFound 79 route exists for a subsuming less specific prefix. 81 The DISR policy applies in addition to (1) preferring Valid when more 82 than one route exists for the same prefix, and (2) NotFound routes 83 are always included in the best path selection process. Note that 84 the existence of a NotFound route excludes the possibility of an 85 alternate Valid or Invalid route for the same prefix or a subsuming 86 less specific prefix. 88 This document also provides an algorithm for best path selection 89 policy that considers Origin Validation (OV) outcome and includes the 90 DISR policy. 92 2. Drop Invalid if Still Routable (DISR) Policy 94 When origin validation (OV) is performed on a BGP route, there are 95 three possible outcomes: (1) Valid, (2) Invalid, or (3) NotFound (see 96 definitions in [RFC6811]). During partial/incremental deployment of 97 RPKI and Route Origin Authorizations, it is natural to always include 98 Valid and NotFound routes in the path selection decision process. 99 (Note: Valid and NotFound are mutually exclusive, i.e., there cannot 100 be two routes for a prefix where one is Valid and the other is 101 NotFound. The same is also true about Invalid and NotFound.) If 102 Invalid routes are always dropped from consideration, then there 103 would be no tolerance for missing or erroneously created ROAs for 104 customer prefixes. Then, the question arises: Should an Invalid 105 route be dropped only if another Valid or NotFound route exists for 106 subsuming a less specific prefix? This policy is called Drop Invalid 107 if Still Routable (DISR). 109 2.1. Motivation for the DISR Policy 111 Consider these scenarios: 113 Scenario 1: A transit ISP A (AS A) created a ROA for a /22 prefix 114 they announce. They also announce a /24 prefix (subsumed in the /22) 115 that is owned by directly-connected customer X (has no AS). But ISP 116 A neglected to create a ROA for X's /24 prefix. Clearly, the 117 announcement of X's /24 will be Invalid. ISP A happens to propagate 118 to neighbors the /22 and the /24. 120 Scenario 2: Customer X (AS X) announces a /22 prefix to transit ISP A 121 and a /24 prefix (subsumed in the /22) to transit ISP B. X is 122 attempting to do traffic engineering (TE). X created a ROA for the 123 /22, but neglected to have ROA coverage for the /24. Clearly, X's 124 announcement of the /24 will be Invalid. X happens to propagate the 125 /24 to ISP B; ISP B does not participate in OV and propagates the 126 Invalid route to its neighbors. 128 In each of the above scenarios, DISR policy (applied at routers 129 elsewhere in the Internet) ensures that traffic for the more specific 130 (/24) still reaches the correct destination, i.e., customer X (albeit 131 possibly via a suboptimal / non-TE path). Any actual hijacks of the 132 /24 prefix would be dropped at all eBGP routers that employ the DISR 133 policy. 135 Measurements show that there are 10,417 Invalid prefix-origin pairs 136 in the global Internet (based on NIST Routeviews/RPKI/ROA data 137 analysis, February 2018). Of these, 6846 are Invalid due to 138 maxlength violation. 6027 (of the 6846) are seen to be routable via 139 Valid or NotFound routes for the same prefix (as in the Invalid 140 route) or a subsuming less specific prefix. Again, 5987 (of the 141 6027) are routes for which the corresponding Valid or NotFound routes 142 (with the same or subsuming less specific prefix) have the exact same 143 origin AS as in the Invalid route in question. These measurements 144 show that Scenarios 1 and 2 described above do occur in significant 145 numbers currently. So, the data lends support the efficacy of the 146 DISR policy in terms of delivering the data traffic to the right 147 destination (though not necessarily via the optimal/TE path). 149 The following is recommended in BCP 185 [RFC7115]: "Before issuing a 150 ROA for a super-block, an operator MUST ensure that all sub- 151 allocations from that block that are announced by other ASes, e.g., 152 customers, have correct ROAs in the RPKI." However, as seen by the 153 above measurement data, there are lapses in following this 154 recommendation. 156 Network operators who do not wish to drop Invalid routes outright 157 (during partial deployment or possibly in transient conditions), 158 SHOULD consider employing the DISR policy. It helps eliminate actual 159 prefix hijacks, while incentivizing creation of required ROAs and the 160 adherence to the above recommendation from BCP 185. The stick used 161 here is the possibility of data traveling via a suboptimal path, 162 while the more aggressive stick of dropping all Invalid routes is 163 held in abeyance. 165 3. Algorithm for Implementation of DISR Policy 167 An algorithm for implementation of the DISR policy is as follows. 169 Perform the following steps when a route is received: 171 1. Perform OV [RFC6811]. 173 2. The second step consists of: 175 * Modify LOCAL_PREF value: Add Kv if Valid; Add Knf if NotFound; 176 Add Ki if Invalid (Kv > Knf >> Ki). 178 * Store the route in RIB-in. 180 3. Apply route selection algorithm (this includes consideration of 181 LOCAL_PREF and other parameters such as MED, etc. in the 182 appropriate order [RFC4271]). 184 4. If selected route is Valid/NotFound, then add the route to Loc- 185 RIB; Else, if Invalid, then add the route to Loc-RIB only if 186 there is no existing route in the Loc-RIB for a subsuming Less 187 Specific prefix. 189 Additional steps in the algorithm that are performed in reaction to 190 addition/withdrawal of routes that influence DISR policy decisions 191 and due to changes in RPKI: 193 a. When a Valid/NotFound route is added to Loc-RIB, check to see if 194 there are any more-specific prefixes subsumed by the route prefix 195 that are in Loc-RIB; If such more-specific prefix is Invalid, 196 then remove it from Loc-RIB. 198 b. When a Valid/NotFound route is withdrawn from Loc-RIB, check to 199 see if there are any more-specifics prefixes subsumed by the 200 route prefix that are in RIB-in; If such more-specific prefix is 201 Invalid, then rerun the route selection decision (Steps 3 and 4 202 above) for it. 204 c. When router learns of RPKI state change, then list all the 205 prefixes effected by it. Rerun Steps 1 through 4 for those 206 prefixes. 208 4. Security Considerations 210 This document addresses some aspects of best common practices for 211 origin validation and related BGP policy. The security 212 considerations provided in RFC 6811 [RFC6811] and BCP 185 [RFC7115] 213 also apply here. 215 5. Normative References 217 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 218 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 219 DOI 10.17487/RFC4271, January 2006, 220 . 222 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 223 Resource Certificate Repository Structure", RFC 6481, 224 DOI 10.17487/RFC6481, February 2012, 225 . 227 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 228 Origin Authorizations (ROAs)", RFC 6482, 229 DOI 10.17487/RFC6482, February 2012, 230 . 232 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 233 Austein, "BGP Prefix Origin Validation", RFC 6811, 234 DOI 10.17487/RFC6811, January 2013, 235 . 237 [RFC7115] Bush, R., "Origin Validation Operation Based on the 238 Resource Public Key Infrastructure (RPKI)", BCP 185, 239 RFC 7115, DOI 10.17487/RFC7115, January 2014, 240 . 242 Acknowledgements 244 The authors wish to thank Sebastian Spies for discussions related to 245 this work. Also, thanks are due to Lilia Hannachi for her insightful 246 analysis of global RPKI and BGP data that has been helpful in this 247 work. 249 Authors' Addresses 251 Kotikalapudi Sriram 252 USA National Institute of Standards and Technology 254 Email: ksriram@nist.gov 256 Oliver Borchert 257 USA National Institute of Standards and Technology 259 Email: oliver.borchert@nist.gov 261 Doug Montgomery 262 USA National Institute of Standards and Technology 264 Email: dougm@nist.gov