idnits 2.17.1 draft-ymbk-sidrops-rov-no-rr-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 draft header indicates that this document updates RFC8481, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (15 November 2021) is 865 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 (-12) exists of draft-ietf-sidrops-8210bis-03 == Outdated reference: A later version (-17) exists of draft-ietf-sidrops-aspa-verification-08 Summary: 0 errors (**), 0 flaws (~~), 4 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: 19 May 2022 P. Smith 7 PFS Internet Development Pty Ltd 8 M. Tinka 9 SEACOM 10 15 November 2021 12 RPKI-Based Policy Without Route Refresh 13 draft-ymbk-sidrops-rov-no-rr-02 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 19 May 2022. 46 Copyright Notice 48 Copyright (c) 2021 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 Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . 3 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 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 depoyed, some router 101 implementations have been found which, when receiving new RPKI data 102 (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 chosn as best path due to RPKI-based policy (ROV, ASPA, 125 etc.), those paths MUST be saved and marked so that later VRPs can 126 reevaluate them against then current policy. 128 As storing these paths could cause problems in resource constrained 129 devices, there MUST be a knob allowing operator control of this 130 feature. Such a knob MUST NOT be per peer, as this could cause 131 inconsistent behavior. 133 5. Operational Recommendations 135 Routers MUST either keep the full Adj-RIB-In or implement the 136 specification in Section 4. 138 Operators deploying ROV and/or other RPKI based policies SHOULD 139 ensure that the router implementation is not causing unnecessary 140 Route Refresh requests to neighbors. 142 If the router does not implement these recommendations, the operator 143 SHOULD enable the vendor's knob to keep the full Adj-RIB-In, 144 sometimes referred to as "soft reconfiguration inbound". The 145 operator should then measure to ensure that there are no unnecessary 146 Route Refresh requests sent to neighbors. 148 If the router has insufficient resources to support this, it MUST not 149 be used for Route Origin Validation. I.e. the knob in Section 4 150 should only be used in very well known and controlled circumstances. 152 Internet Exchange Points which provide [RFC7947] Route Servers should 153 be aware that some members could be causing an undue Route Refresh 154 load on the Route Servers and take appropriate administrative and/or 155 technical measures. 157 6. Security Considerations 159 This document describes a denial of service which Route Origin 160 Validation or other RPKI policy may place on a BGP neighbor, and 161 describes how it may be ameliorated. 163 Otherwise, this document adds no additional security considerations 164 to those already described by the referenced documents. 166 7. IANA Considerations 168 None 170 8. Acknowledgements 172 The authors wish to thank Ben Maddison and Nick Hilliard. 174 9. References 176 9.1. Normative References 178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels", BCP 14, RFC 2119, 180 DOI 10.17487/RFC2119, March 1997, 181 . 183 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 184 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 185 DOI 10.17487/RFC4271, January 2006, 186 . 188 [RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced 189 Route Refresh Capability for BGP-4", RFC 7313, 190 DOI 10.17487/RFC7313, July 2014, 191 . 193 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 194 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 195 May 2017, . 197 9.2. Informative References 199 [I-D.ietf-sidrops-8210bis] 200 Bush, R. and R. Austein, "The Resource Public Key 201 Infrastructure (RPKI) to Router Protocol, Version 2", Work 202 in Progress, Internet-Draft, draft-ietf-sidrops-8210bis- 203 03, 15 August 2021, . 206 [I-D.ietf-sidrops-aspa-verification] 207 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and J. 208 Snijders, "Verification of AS_PATH Using the Resource 209 Certificate Public Key Infrastructure and Autonomous 210 System Provider Authorization", Work in Progress, 211 Internet-Draft, draft-ietf-sidrops-aspa-verification-08, 212 25 August 2021, . 215 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 216 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 217 February 2012, . 219 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 220 Origin Authorizations (ROAs)", RFC 6482, 221 DOI 10.17487/RFC6482, February 2012, 222 . 224 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 225 Austein, "BGP Prefix Origin Validation", RFC 6811, 226 DOI 10.17487/RFC6811, January 2013, 227 . 229 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 230 "Internet Exchange BGP Route Server", RFC 7947, 231 DOI 10.17487/RFC7947, September 2016, 232 . 234 [RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based 235 on Resource Public Key Infrastructure (RPKI)", RFC 8481, 236 DOI 10.17487/RFC8481, September 2018, 237 . 239 Authors' Addresses 241 Randy Bush 242 IIJ Research Lab & Arrcus, Inc. 243 1856 SW Edgewood Dr 244 Portland, Oregon 97210 245 United States of America 247 Email: randy@psg.com 249 Keyur Patel 250 Arrcus, Inc. 251 2077 Gateway Place, Suite #400 252 San Jose, CA 95119 253 United States of America 255 Email: keyur@arrcus.com 257 Philip Smith 258 PFS Internet Development Pty Ltd 259 PO Box 1908 260 Milton QLD 4064 261 Australia 263 Email: pfsinoz@gmail.com 265 Mark Tinka 266 SEACOM 267 Building 7, Design Quarter District, Leslie Avenue, Magaliessig 268 Fourways, Gauteng 269 2196 270 South Africa 272 Email: mark@tinka.africa