idnits 2.17.00 (12 Aug 2021) /tmp/idnits52790/draft-ietf-sidrops-rov-no-rr-01.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 either of the two proposed options, 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 (6 May 2022) is 8 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: 7 November 2022 P. Smith 7 PFS Internet Development Pty Ltd 8 M. Tinka 9 SEACOM 10 6 May 2022 12 RPKI-Based Policy Without Route Refresh 13 draft-ietf-sidrops-rov-no-rr-01 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 7 November 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 and 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 due to ROV, 124 those paths MUST NOT be evaluated for best path, but MUST be saved 125 (either separately or marked) so they may be reevaluated with respect 126 to new RPKI data. 128 If new RPKI data arrive which invalidate the best path, and the 129 router did not keep all alternatives, then it MUST issue a route 130 refresh so those alternatives may be evaluated for best path. 132 Policy which may drop paths due to RPKI-based checks such as ROV, 133 ASPA, BGPsec [RFC8205], etc. MUST be run, and the dropped paths 134 saved per the above paragraph, before non-RPKI policies are run, as 135 the latter may change path attributes. 137 As storing these paths could cause problems in resource constrained 138 devices, there MUST be a knob allowing operator control of this 139 feature. Such a knob MUST NOT be per peer, as this could cause 140 inconsistent behavior. 142 If Route Refresh has been issued toward more than one peer, the order 143 of receipt of the refresh data can cause churn in both best path 144 selection and in outbound signaling. 146 5. Operational Recommendations 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 Routers MUST either keep the full Adj-RIB-In or implement the 153 specification in Section 4. 155 If the router does not implement these recommendations, the operator 156 SHOULD enable the vendor's knob to keep the full Adj-RIB-In, 157 sometimes referred to as "soft reconfiguration inbound". The 158 operator should then measure to ensure that there are no unnecessary 159 Route Refresh requests sent to neighbors. 161 If the router has insufficient resources to support either of the two 162 proposed options, it MUST not be used for Route Origin Validation. 163 I.e. the knob in Section 4 should only be used in very well known and 164 controlled circumstances. 166 Operators using the specification in Section 4 should be aware that a 167 misconfigured neighbor might erroneously send a massive number of 168 paths, thus consuming a lot of memory. Pre-policy filtering such as 169 described in [I-D.sas-idr-maxprefix-inbound] SHOULD be used to reduce 170 this exposure. 172 Internet Exchange Points (IXPs)which provide [RFC7947] Route Servers 173 should be aware that some members could be causing an undue Route 174 Refresh load on the Route Servers and take appropriate administrative 175 and/or technical measures. IXPs using routers as route servers 176 should ensure that they are not generating excessive route refresh 177 requests. 179 6. Security Considerations 181 This document describes a denial of service which Route Origin 182 Validation or other RPKI policy may place on a BGP neighbor, and 183 describes how it may be ameliorated. 185 Otherwise, this document adds no additional security considerations 186 to those already described by the referenced documents. 188 7. IANA Considerations 190 None 192 8. Acknowledgements 194 The authors wish to thank Ben Maddison, John Heasley, John Scudder, 195 Matthias Waehlisch, Nick Hilliard, Saku Ytti, and Ties de Kock. 197 9. References 199 9.1. Normative References 201 [I-D.sas-idr-maxprefix-inbound] 202 Aelmans, M., Stucchi, M., and J. Snijders, "BGP Maximum 203 Prefix Limits Inbound", Work in Progress, Internet-Draft, 204 draft-sas-idr-maxprefix-inbound-04, 19 January 2022, 205 . 208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, 210 DOI 10.17487/RFC2119, March 1997, 211 . 213 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 214 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 215 DOI 10.17487/RFC4271, January 2006, 216 . 218 [RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced 219 Route Refresh Capability for BGP-4", RFC 7313, 220 DOI 10.17487/RFC7313, July 2014, 221 . 223 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 224 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 225 May 2017, . 227 9.2. Informative References 229 [I-D.ietf-sidrops-8210bis] 230 Bush, R. and R. Austein, "The Resource Public Key 231 Infrastructure (RPKI) to Router Protocol, Version 2", Work 232 in Progress, Internet-Draft, draft-ietf-sidrops-8210bis- 233 06, 15 February 2022, . 236 [I-D.ietf-sidrops-aspa-verification] 237 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and J. 238 Snijders, "Verification of AS_PATH Using the Resource 239 Certificate Public Key Infrastructure and Autonomous 240 System Provider Authorization", Work in Progress, 241 Internet-Draft, draft-ietf-sidrops-aspa-verification-08, 242 25 August 2021, . 245 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 246 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 247 February 2012, . 249 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 250 Origin Authorizations (ROAs)", RFC 6482, 251 DOI 10.17487/RFC6482, February 2012, 252 . 254 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 255 Austein, "BGP Prefix Origin Validation", RFC 6811, 256 DOI 10.17487/RFC6811, January 2013, 257 . 259 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 260 "Internet Exchange BGP Route Server", RFC 7947, 261 DOI 10.17487/RFC7947, September 2016, 262 . 264 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 265 Specification", RFC 8205, DOI 10.17487/RFC8205, September 266 2017, . 268 [RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based 269 on Resource Public Key Infrastructure (RPKI)", RFC 8481, 270 DOI 10.17487/RFC8481, September 2018, 271 . 273 Authors' Addresses 274 Randy Bush 275 IIJ Research Lab & Arrcus, Inc. 276 1856 SW Edgewood Dr 277 Portland, Oregon 97210 278 United States of America 279 Email: randy@psg.com 281 Keyur Patel 282 Arrcus, Inc. 283 2077 Gateway Place, Suite #400 284 San Jose, CA 95119 285 United States of America 286 Email: keyur@arrcus.com 288 Philip Smith 289 PFS Internet Development Pty Ltd 290 PO Box 1908 291 Milton QLD 4064 292 Australia 293 Email: pfsinoz@gmail.com 295 Mark Tinka 296 SEACOM 297 Building 7, Design Quarter District, Leslie Avenue, Magaliessig 298 Fourways, Gauteng 299 2196 300 South Africa 301 Email: mark@tinka.africa