idnits 2.17.1 draft-ietf-sidrops-rpki-rov-timing-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (16 August 2021) is 977 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-sidrops-8210bis-02 ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) == Outdated reference: A later version (-02) exists of draft-ietf-sidrops-prefer-rrdp-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft Internet Initiative Japan & Arrcus, Inc. 4 Intended status: Informational J. Borkenhagen 5 Expires: 17 February 2022 AT&T 6 T. Bruijnzeels 7 NLnet Labs 8 J. Snijders 9 Fastly 10 16 August 2021 12 Timing Parameters in the RPKI based Route Origin Validation Supply Chain 13 draft-ietf-sidrops-rpki-rov-timing-05 15 Abstract 17 This document explores, and makes recommendations for, timing of 18 Resource Public Key Infrastructure publication of ROV data, their 19 propagation, and their use in Relying Parties and routers. 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 17 February 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Certification Authority Publishing . . . . . . . . . . . . . 4 65 4. Relying Party Fetching . . . . . . . . . . . . . . . . . . . 4 66 5. Router Updating . . . . . . . . . . . . . . . . . . . . . . . 5 67 6. Effect on Routing . . . . . . . . . . . . . . . . . . . . . . 5 68 7. Alternative Technologies . . . . . . . . . . . . . . . . . . 6 69 8. Operational Expectations . . . . . . . . . . . . . . . . . . 6 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 11.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 This document explores, and makes recommendations for, timing of 81 Resource Public Key Infrastructure (RPKI) publication of ROV data, 82 their propagation, and their use in Relying Parties (RP), caches and 83 routers. 85 The RPKI supply chain from CAs to reach routers has the following 86 structure: 88 Cerification Authorities: The authoritative data of the RPKI are 89 meant to be published by a distributed set of Certification 90 Authorities (CAs) at the IANA, RIRs, NIRs, and ISPs (see 91 [RFC6481]). 93 Publication Points: The CAs publish their authoritative data in 94 publicly accessible repositories which have a Publication Point 95 (PP) for each CA. A CA may publish directly at a PP or may use 96 the RPKI Publication Protocol [RFC8181]. 98 Relying Parties: Relying Parties are a local (to the routers) set of 99 one or more collected and verified caches of RPKI data which the 100 RPs collect from the PPs. 102 Currently RPs can pull from other RPs, thereby allowing a somewhat 103 complex topology. 105 Routers: Validating routers fetch data from local RP caches using 106 the RPKI to Router Protocol, [I-D.ietf-sidrops-8210bis]. Routers 107 are clients of the caches. Validating routers MUST have a trust 108 relationship with, and a trusted transport channel to, any RP(s) 109 they use. [I-D.ietf-sidrops-8210bis] specifies mechanisms for a 110 router to assure itself of the authenticity of the cache(s) and to 111 authenticate itself to cache(s). 113 As Resource Public Key Infrastructure based Route Origin Validation 114 (ROV) becomes deployed in the Internet, the quality of the routing 115 control plane, and hence timely and accurate delivery of packets in 116 the data plane, increasingly depend on prompt and accurate 117 propagation of the RPKI data from the originating Certification 118 Authorities (CAs), to Relying Parties (RPs), to Border Gateway 119 Protocol (BGP) speaking routers. 121 Origin Validation based on stale ROAs allows accidental or 122 intentional mis-origination; announcement of a prefix by an AS which 123 does not have the authority to do so. Delays in ROA propagation to 124 ROV in routers might cause loss of good traffic. Therefore 125 minimizing propagation time of data from CAs to routers is important. 127 Before the data can start on the CA to router supply chain, the 128 resource holder (operator) MUST create or delete the relevant ROA(s) 129 through the CA's operational interface(s). The operator is 130 responsible for anticipating their future needs for ROAs, be aware of 131 the propagation time from creating ROAs to effect on routing, and 132 SHOULD create, delete, or modify ROAs sufficiently in advance of any 133 needs in the routing system. 135 There are questions of how frequently a CA publishes, how often an RP 136 pulls, and how often routers pull from their RP(s). Overall, the 137 router(s) SHOULD react within an hour of ROA publication. 139 For CAs publishing to PPs, a few seconds to a minute seems easily 140 achieved with reasonable software. See Section 3. 142 Relying Party validating caches periodically retrieve data from CA 143 publication points. RPs using rsync to poll publication points every 144 ten minutes would be a burden today, given the load it would put on 145 publication services, cf. one notorious repository which was 146 structured against specification. RPs using RRDP impose less load. 147 As the infrastructure moves from rsync to RRDP 148 [I-D.ietf-sidrops-prefer-rrdp], RRDP is designed for quite frequent 149 polling as long as Relying Parties use the "If-Modified-Since" header 150 and there is a caching infrastructure. For rsync, an hour would be 151 the longest acceptable window and half an hour the shortest. See 152 Section 4. 154 For BGP speaking router(s) pulling from the RP(s), five minutes to an 155 hour is a wide window. But, the RPKI-Rtr protocol does have the 156 Serial Notify PDU, the equivalent of DNS Notify, where the cache 157 tells the router that it has new data. See Section 5. 159 We discuss each of these in detail below. 161 2. Related Work 163 It is assumed that the reader understands BGP, [RFC4271], the RPKI 164 [RFC6480], RPKI Manifests [RFC6486], Route Origin Authorizations 165 (ROAs), [RFC6482], the RPKI Repository Delta Protocol (RRDP) 166 [RFC8182], The Resource Public Key Infrastructure (RPKI) to Router 167 Protocol [I-D.ietf-sidrops-8210bis], RPKI-based Prefix Validation, 168 [RFC6811], and Origin Validation Clarifications, [RFC8481]. 170 3. Certification Authority Publishing 172 A principal constraint on publication timing is ensuring the CRL and 173 Manifest ([RFC6486]) are atomically correct with respect to the other 174 repository data. With rsync, the publication point must be 175 atomically correct before it becomes current. RRDP ([RFC8182]) is 176 similar, the publication point must be atomically correct before it 177 is published. 179 4. Relying Party Fetching 181 rsync puts a load on RPKI publication point servers. Therefore 182 relying party caches have been discouraged from fetching more 183 frequently than on the order of a half hour. Times as long as a day 184 were even suggested. We conclude that RPs using rsync SHOULD pull 185 from CA publication points every 30 to 60 minutes. 187 With RRDP ([RFC8182]), such constraints are less relevant. [RFC8182] 188 makes clear that polling as no more frequently than once a minute is 189 acceptable iff Relying Parties use the If-Modified-Since header and 190 there is caching. Absent use of the If-Modified-Since header, the 191 RRDP polling interval MUST NOT be more frequent than ten minutes. 192 Use of the If-Modified-Since header is strongly recommended. 194 Migration from rsync to RRDP in [I-D.ietf-sidrops-prefer-rrdp] is 195 recommended. During dual RRDP/rsync operation, should an RP need to 196 fall over from RRDP to rsync, a uniformly distribued jittered delay 197 with a mean of half the rsync interval SHOULD be used; so clients 198 falling over to rsync are as spread out as they would be if they used 199 rsync initallly. 201 A number of timers are embedded in the X.509 RPKI data which should 202 also be considered. E.g., CRL publication commitments, expiration of 203 EE certificates pointing to Manifests, and the Manifests themselves. 204 Some CA operators commonly indicate new CRL information should be 205 available in the next 24 hours. These 24 hour sliding timers, when 206 combined with fetching RPKI data once a day, would expose failure 207 windows, especially in the face of transient network issues between 208 the CA and RP. To ameliorate this, RPs SHOULD update from CAs every 209 hour or two at most. 211 5. Router Updating 213 The rate of change of ROA data is estimated to remain small, on the 214 order of a few ROAs a minute, but with bursts. Therefore, the 215 routers may update from the (presumed local) relying party cache(s) 216 quite frequently. Note that [I-D.ietf-sidrops-8210bis] recommends a 217 polling interval of one hour. This polling timing is conservative 218 because caches can send a Serial Notify PDU to tell routers when 219 there are new data to be fetched. As the RP cache and the router 220 belong to the same operator, routers are free to hammer the RPs as 221 frequently as they wish. 223 A router SHOULD respond with a Serial Query when it receives a Serial 224 Notify from a cache. If a router can not respond appropriately to a 225 Serial Notify, then it MUST send a periodic Serial Query no less 226 frequently than once an hour. 228 6. Effect on Routing 230 Once a router has received an End of Data PDU from a cache, the 231 effect on Route Origin Validation MUST be a matter of seconds to a 232 minute. The router MAY allow incoming VRPs to affect Origin 233 Validation as they arrive instead of waiting for the End of Data PDU. 234 See [I-D.ietf-sidrops-8210bis] for some cautions regarding the 235 arrival sequence of VRPs. 237 7. Alternative Technologies 239 Should the supply chain include components or technologies other than 240 those in IETF documents, the end effect SHOULD be the same; the 241 router(s) SHOULD react to invalid AS origins within the same overall 242 time constraint, an hour at most from ROA creation at the CA 243 publication point to effect in the router. 245 8. Operational Expectations 247 Assuming the above recommendations, in worst conditions such as an 248 RPKI-rtr Notify PDU being ignored, it may take up to two hours for a 249 new ROA to propagate from creation at the CA to BGP speaking routers. 250 Therefore it is RECOMMENDED that planned changes in ROAs take this 251 propagation time into consideration. E.g. if a new route is to be 252 announced in BGP, the operators SHOULD create the ROA around three 253 hours before BGP announcement, or it may not propagate globally. 255 9. Security Considerations 257 Despite common misconceptions and marketing, Route Origin Validation 258 is not a magic security protocol. It is intended to catch 259 operational errors, and is easily gamed and attacked through, for 260 example, AS Path manipulation. It is one tool in the prudent 261 operator's kit, and a good one. 263 If an attacker can add, delete, or modify RPKI data, either in 264 repositories or in flight, they can affect routing and thereby steer 265 or damage traffic. The RPKI system design does much to deter these 266 attacks. But the 'last mile' from the cache to the router uses 267 transport, as opposed to object, security and is vulnerable. This is 268 discussed in [I-D.ietf-sidrops-8210bis]. 270 Similarly, if an attacker can delay prompt propagation of RPKI data 271 on the supply chain described in this document, they can affect 272 routing, and therefore traffic flow, to their advantage. 274 10. IANA Considerations 276 None 278 11. References 280 11.1. Normative References 282 [I-D.ietf-sidrops-8210bis] 283 Bush, R. and R. Austein, "The Resource Public Key 284 Infrastructure (RPKI) to Router Protocol, Version 2", Work 285 in Progress, Internet-Draft, draft-ietf-sidrops-8210bis- 286 02, 18 February 2021, . 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, 291 DOI 10.17487/RFC2119, March 1997, 292 . 294 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 295 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 296 DOI 10.17487/RFC4271, January 2006, 297 . 299 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 300 Resource Certificate Repository Structure", RFC 6481, 301 DOI 10.17487/RFC6481, February 2012, 302 . 304 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 305 Origin Authorizations (ROAs)", RFC 6482, 306 DOI 10.17487/RFC6482, February 2012, 307 . 309 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 310 "Manifests for the Resource Public Key Infrastructure 311 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 312 . 314 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 315 Austein, "BGP Prefix Origin Validation", RFC 6811, 316 DOI 10.17487/RFC6811, January 2013, 317 . 319 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 320 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 321 May 2017, . 323 [RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication 324 Protocol for the Resource Public Key Infrastructure 325 (RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017, 326 . 328 [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 329 "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, 330 DOI 10.17487/RFC8182, July 2017, 331 . 333 [RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based 334 on Resource Public Key Infrastructure (RPKI)", RFC 8481, 335 DOI 10.17487/RFC8481, September 2018, 336 . 338 11.2. Informative References 340 [I-D.ietf-sidrops-prefer-rrdp] 341 Bruijnzeels, T., Bush, R., and G. Michaelson, "Resource 342 Public Key Infrastructure (RPKI) Repository Requirements", 343 Work in Progress, Internet-Draft, draft-ietf-sidrops- 344 prefer-rrdp-00, 22 February 2021, 345 . 348 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 349 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 350 February 2012, . 352 Appendix A. Acknowledgements 354 The authors wish to thank Massimiliano Stucchi and Ties de Kock. 356 Authors' Addresses 358 Randy Bush 359 Internet Initiative Japan & Arrcus, Inc. 360 5147 Crystal Springs 361 Bainbridge Island, Washington 98110 362 United States of America 364 Email: randy@psg.com 366 Jay Borkenhagen 367 AT&T 368 200 Laurel Avenue South 369 Middletown, NJ 07748 370 United States of America 372 Email: jayb@att.com 374 Tim Bruijnzeels 375 NLnet Labs 377 Email: tim@nlnetlabs.nl 378 URI: https://www.nlnetlabs.nl/ 379 Job Snijders 380 Fastly 381 Amsterdam 382 Netherlands 384 Email: job@fastly.com