idnits 2.17.00 (12 Aug 2021) /tmp/idnits49964/draft-i-sidrops-rov-no-rr-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 draft header indicates that this document updates RFC8481, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the router has insufficient resources to support this, it MUST not be used for Route Origin Validation. I.e. the knob in Section 4 should only be used in very well known and controlled circumstances. -- The document date (27 January 2022) is 107 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-ietf-sidrops-8210bis-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft IIJ Research Lab & Arrcus, Inc. 4 Updates: 8481 (if approved) K. Patel 5 Intended status: Standards Track Arrcus, Inc. 6 Expires: 31 July 2022 P. Smith 7 PFS Internet Development Pty Ltd 8 M. Tinka 9 SEACOM 10 27 January 2022 12 RPKI-Based Policy Without Route Refresh 13 draft-i-sidrops-rov-no-rr-00 15 Abstract 17 A BGP Speaker performing RPKI-based policy should not issue Route 18 Refresh to its neighbors when receiving new RPKI data. A method for 19 avoiding doing so is described. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 25 "OPTIONAL" in this document are to be interpreted as described in BCP 26 14 [RFC2119] [RFC8174] when, and only when, they appear in all 27 capitals, as shown here. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 31 July 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. ROV Experience . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Keeping Partial Adj-RIB-In Data . . . . . . . . . . . . . . . 3 66 5. Operational Recommendations . . . . . . . . . . . . . . . . . 4 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 72 9.2. Informative References . . . . . . . . . . . . . . . . . 5 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 Memory constraints in early routers caused classic [RFC4271] BGP 78 implementations to not keep a full Adj-RIB-In (Sec. 1.1). When doing 79 RPKI-based Route Origin Validation ([RFC6811] and [RFC8481]), and 80 similar RPKI-based policy, if such a BGP speaker receives new RPKI 81 data, it might not have kept paths previously marked as Invalid etc. 82 Such an implementation must then request a Route Refresh [RFC7313] 83 from its neighbors to recover the paths which might be covered by 84 these new RPKI data. This will be perceived as rude by those 85 neighbors as it passes a serious resource burden on to them. This 86 document recommends implementations keep but mark paths affected by 87 RPKI-based policy so Route Refresh is no longer needed. 89 2. Related Work 91 It is assumed that the reader understands BGP, [RFC4271] and Route 92 Refresh [RFC7313], the RPKI [RFC6480], Route Origin Authorizations 93 (ROAs), [RFC6482], The Resource Public Key Infrastructure (RPKI) to 94 Router Protocol [I-D.ietf-sidrops-8210bis], RPKI-based Prefix 95 Validation, [RFC6811], and Origin Validation Clarifications, 96 [RFC8481]. 98 3. ROV Experience 100 As Route Origin Validation dropping Invalids has deployed, some 101 router implementations have been found which, when receiving new RPKI 102 data (VRPs, see [I-D.ietf-sidrops-8210bis]) issue a BGP Route Refresh 103 [RFC7313] to all sending BGP peers so that it can reevaluate the 104 received paths aginst the new data. 106 In actual deployment this has been found to be very destructive, 107 transferring a serious resource burden to the unsuspecting peers. In 108 reaction, RPKI based Route Origin Validation (ROV) has been turned 109 off; and there have been actual de-peerings. 111 As RPKI registration and ROA creation have steadily increased, this 112 problem has increased, not just proportionally, but on the order of 113 the in-degree of ROV implementing routers. As ASPA 114 ([I-D.ietf-sidrops-aspa-verification]) becomes used, the problem will 115 increase. 117 4. Keeping Partial Adj-RIB-In Data 119 Ameliorating this problem by keeping a full Adj-RIB-In can be a 120 problem for resource constrained routers. In reality, only some data 121 need be retained. 123 When RPKI data cause one or more paths to be dropped, withdrawn, or 124 merely not chosen as best path due to RPKI-based policy (ROV, ASPA, 125 etc.), those paths MUST be saved and marked (to not be used for best 126 path evaluation etc.) so that later VRPs can reevaluate them against 127 then current policy. 129 Policy which may drop paths due to RPKI-based checks such as ROV, 130 ASPA, BGPsec, etc. MUST be run, and the dropped paths saved per the 131 above paragraph, before non-RPKI policies are run, as the latter may 132 change path attributes. 134 As storing these paths could cause problems in resource constrained 135 devices, there MUST be a knob allowing operator control of this 136 feature. Such a knob MUST NOT be per peer, as this could cause 137 inconsistent behavior. 139 If Route Refresh has been issued toward more than one peer, the order 140 of receipt of the refresh data can cause churn in both best path 141 selection and in outbound signaling. 143 5. Operational Recommendations 145 Routers MUST either keep the full Adj-RIB-In or implement the 146 specification in Section 4. 148 Operators deploying ROV and/or other RPKI based policies SHOULD 149 ensure that the router implementation is not causing unnecessary 150 Route Refresh requests to neighbors. 152 If the router does not implement these recommendations, the operator 153 SHOULD enable the vendor's knob to keep the full Adj-RIB-In, 154 sometimes referred to as "soft reconfiguration inbound". The 155 operator should then measure to ensure that there are no unnecessary 156 Route Refresh requests sent to neighbors. 158 If the router has insufficient resources to support this, it MUST not 159 be used for Route Origin Validation. I.e. the knob in Section 4 160 should only be used in very well known and controlled circumstances. 162 Operators using the specification in Section 4 should be aware that a 163 misconfigured neighbor might erroneously send a massive number of 164 paths, thus consuming a lot of memory. Pre-policy filtering such as 165 described in [I-D.sas-idr-maxprefix-inbound] SHOULD be used to reduce 166 this exposure. 168 Internet Exchange Points (IXPs)which provide [RFC7947] Route Servers 169 should be aware that some members could be causing an undue Route 170 Refresh load on the Route Servers and take appropriate administrative 171 and/or technical measures. IXPs using routers as route servers 172 should ensure that they are not generating excessive route refresh 173 requests. 175 6. Security Considerations 177 This document describes a denial of service which Route Origin 178 Validation or other RPKI policy may place on a BGP neighbor, and 179 describes how it may be ameliorated. 181 Otherwise, this document adds no additional security considerations 182 to those already described by the referenced documents. 184 7. IANA Considerations 186 None 188 8. Acknowledgements 190 The authors wish to thank Ben Maddison, John Heasley, Nick Hilliard, 191 John Scudder, Matthias Waehlisch, and Saku Ytti. 193 9. References 195 9.1. Normative References 197 [I-D.sas-idr-maxprefix-inbound] 198 Aelmans, M., Stucchi, M., and J. Snijders, "BGP Maximum 199 Prefix Limits Inbound", Work in Progress, Internet-Draft, 200 draft-sas-idr-maxprefix-inbound-04, 19 January 2022, 201 . 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, 206 DOI 10.17487/RFC2119, March 1997, 207 . 209 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 210 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 211 DOI 10.17487/RFC4271, January 2006, 212 . 214 [RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced 215 Route Refresh Capability for BGP-4", RFC 7313, 216 DOI 10.17487/RFC7313, July 2014, 217 . 219 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 220 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 221 May 2017, . 223 9.2. Informative References 225 [I-D.ietf-sidrops-8210bis] 226 Bush, R. and R. Austein, "The Resource Public Key 227 Infrastructure (RPKI) to Router Protocol, Version 2", Work 228 in Progress, Internet-Draft, draft-ietf-sidrops-8210bis- 229 05, 22 December 2021, . 232 [I-D.ietf-sidrops-aspa-verification] 233 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and J. 234 Snijders, "Verification of AS_PATH Using the Resource 235 Certificate Public Key Infrastructure and Autonomous 236 System Provider Authorization", Work in Progress, 237 Internet-Draft, draft-ietf-sidrops-aspa-verification-08, 238 25 August 2021, . 241 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 242 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 243 February 2012, . 245 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 246 Origin Authorizations (ROAs)", RFC 6482, 247 DOI 10.17487/RFC6482, February 2012, 248 . 250 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 251 Austein, "BGP Prefix Origin Validation", RFC 6811, 252 DOI 10.17487/RFC6811, January 2013, 253 . 255 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 256 "Internet Exchange BGP Route Server", RFC 7947, 257 DOI 10.17487/RFC7947, September 2016, 258 . 260 [RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based 261 on Resource Public Key Infrastructure (RPKI)", RFC 8481, 262 DOI 10.17487/RFC8481, September 2018, 263 . 265 Authors' Addresses 267 Randy Bush 268 IIJ Research Lab & Arrcus, Inc. 269 1856 SW Edgewood Dr 270 Portland, Oregon 97210 271 United States of America 272 Email: randy@psg.com 274 Keyur Patel 275 Arrcus, Inc. 276 2077 Gateway Place, Suite #400 277 San Jose, CA 95119 278 United States of America 280 Email: keyur@arrcus.com 282 Philip Smith 283 PFS Internet Development Pty Ltd 284 PO Box 1908 285 Milton QLD 4064 286 Australia 288 Email: pfsinoz@gmail.com 290 Mark Tinka 291 SEACOM 292 Building 7, Design Quarter District, Leslie Avenue, Magaliessig 293 Fourways, Gauteng 294 2196 295 South Africa 297 Email: mark@tinka.africa