idnits 2.17.1 draft-ietf-sidrops-rpki-rov-timing-06.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 (7 February 2022) is 809 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-05 ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) == Outdated reference: A later version (-02) exists of draft-ietf-sidrops-prefer-rrdp-01 Summary: 2 errors (**), 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: 11 August 2022 AT&T 6 T. Bruijnzeels 7 NLnet Labs 8 J. Snijders 9 Fastly 10 7 February 2022 12 Timing Parameters in the RPKI based Route Origin Validation Supply Chain 13 draft-ietf-sidrops-rpki-rov-timing-06 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, caches, 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 11 August 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Certification Authority Publishing . . . . . . . . . . . . . 4 65 4. Relying Party Fetching . . . . . . . . . . . . . . . . . . . 5 66 5. Router Updating . . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Effect on Routing . . . . . . . . . . . . . . . . . . . . . . 6 68 7. Alternative Technologies . . . . . . . . . . . . . . . . . . 6 69 8. Operational Expectations . . . . . . . . . . . . . . . . . . 6 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 11.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 ROA supply chain from CAs to when they reach routers has the 86 following 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, [RFC8210] and 107 [I-D.ietf-sidrops-8210bis]. Routers are clients of the caches. 108 Validating routers MUST have a trust relationship with, and a 109 trusted transport channel to, any RP(s) they use. 110 [I-D.ietf-sidrops-8210bis] specifies mechanisms for a router to 111 assure itself of the authenticity of the cache(s) and to 112 authenticate itself to cache(s). 114 As Resource Public Key Infrastructure based Route Origin Validation 115 (ROV) becomes deployed in the Internet, the quality of the routing 116 control plane, and hence timely and accurate delivery of packets in 117 the data plane, increasingly depend on prompt and accurate 118 propagation of the RPKI data from the originating Certification 119 Authorities (CAs), to Relying Parties (RPs), to Border Gateway 120 Protocol (BGP) speaking routers. 122 Origin Validation based on stale ROAs allows accidental or 123 intentional mis-origination; announcement of a prefix by an AS which 124 does not have the authority to do so. Delays in ROA propagation to 125 ROV in routers might cause loss of good traffic. Therefore 126 minimizing propagation time of data from CAs to routers is important. 128 Before the data can start on the CA to router supply chain, the 129 resource holder (operator) MUST create, modify, or delete the 130 relevant ROA(s) through the CA's operational interface(s). The 131 operator is responsible for anticipating their future needs for ROAs, 132 be aware of the propagation time from creating ROAs to effect on 133 routing, and SHOULD create, delete, or modify ROAs sufficiently in 134 advance of any needs in the routing system. 136 There are questions of how frewwww3quently a CA publishes, how often 137 an RP pulls, and how often routers pull from their RP(s). Overall, 138 the router(s) SHOULD react within an hour of ROA publication. In 139 pessimistic circumstances, it could be two hours. 141 For CAs publishing to PPs, a few seconds to a minute seems easily 142 achieved with reasonable software. See Section 3. 144 Relying Party validating caches periodically retrieve data from CA 145 publication points. RPs using rsync to poll publication points every 146 ten minutes would be a burden today, given the load it would put on 147 publication services, cf. one notorious repository which was 148 structured against specification. RPs using RRDP impose less load. 149 As the infrastructure moves from rsync to RRDP 150 [I-D.ietf-sidrops-prefer-rrdp], RRDP is designed for quite frequent 151 polling as long as Relying Parties use the If-Modified-Since (see 152 [RFC7232]) header and there is a caching infrastructure. For rsync, 153 an hour would be the longest acceptable window and half an hour the 154 shortest. See Section 4. 156 For BGP speaking router(s) pulling from the RP(s), five minutes to an 157 hour is a wide window. But, the RPKI-Rtr protocol does have the 158 Serial Notify PDU, the equivalent of DNS Notify [RFC1996], where the 159 cache tells the router that it has new data. See Section 5. 161 We discuss each of these in more detail below. 163 2. Related Work 165 It is assumed that the reader understands BGP, [RFC4271], the RPKI 166 [RFC6480], RPKI Manifests [RFC6486], Route Origin Authorizations 167 (ROAs), [RFC6482], the RPKI Repository Delta Protocol (RRDP) 168 [RFC8182], The Resource Public Key Infrastructure (RPKI) to Router 169 Protocol [I-D.ietf-sidrops-8210bis], RPKI-based Prefix Validation, 170 [RFC6811], and Origin Validation Clarifications, [RFC8481]. 172 3. Certification Authority Publishing 174 One constraint on publication timing can be ensuring the CRL and 175 Manifest ([RFC6486]) are consistent with each other and with respect 176 to the other repository data. With both rsync and RRDP protocols, 177 the publication point MUST be consistent before it becomes current 178 and is published. 180 Operators should beware that there may be implementation dependent 181 delays between instructing their CAs to create and/or update ROAs and 182 the publication of these changes in the PPs. 184 4. Relying Party Fetching 186 rsync puts a load on RPKI publication point servers. Therefore 187 relying party caches have been discouraged from fetching more 188 frequently than on the order of a half hour. Times as long as a day 189 were even suggested. We specify that RPs using rsync SHOULD pull 190 from CA publication points every 30 to 60 minutes. 192 With RRDP ([RFC8182]), such constraints can be less relevant. 193 [RFC8182] makes clear that polling as frequently as once a minute is 194 acceptable if and only if Relying Parties use the If-Modified-Since 195 header and there is caching. Absent use of the If-Modified-Since 196 header, the RRDP polling interval MUST NOT be more frequent than ten 197 minutes. Use of the If-Modified-Since header is strongly 198 RECOMMENDED. 200 Migration from rsync to RRDP in [I-D.ietf-sidrops-prefer-rrdp] is 201 recommended. During dual RRDP/rsync operation, should an RP need to 202 fall over from RRDP to rsync, a uniformly distributed jittered delay 203 with a mean of half the rsync interval SHOULD be used; so clients 204 falling over to rsync are as spread out as they would be if they used 205 rsync initallly. 207 A number of timers are embedded in the X.509 RPKI data which should 208 also be considered. E.g., CRL publication commitments, expiration of 209 EE certificates pointing to Manifests, and the Manifests themselves. 210 Some CA operators commonly indicate new CRL information should be 211 available in the next 24 hours. These 24 hour sliding timers, when 212 combined with fetching RPKI data once a day, would expose failure 213 windows, especially in the face of transient network issues between 214 the CA and RP. To ameliorate this, RPs SHOULD update from CAs at 215 least as frequently as once an hour. 217 In summary, the following timing constraints SHOULD be applied to 218 data update: RPs SHOULD update from CAs at least once an hour. To 219 avoid excess load, RPs SHOULD NOT update via rsync more frequently 220 than every 30 minutes. RPs using RRDP SHOULD NOT need to update more 221 frequently than every 10 minutes. Some form of timing jitter MUST be 222 applied to ensure load distribution across the community. RPs SHOULD 223 NOT force data fetch to be on the hour or similar times. Publication 224 Points SHOULD deploy RRDP services which honor If-Modified-Since. 226 In general, CAs should have Manifest, CRL, ... timers of a few days 227 to allow relying party operators to go away for the weekend and not 228 fear for their control plane. 230 5. Router Updating 232 The rate of change of ROA data is estimated to remain small, on the 233 order of a few ROAs a minute, but with bursts. Therefore, the 234 routers may update from the (presumed local) relying party cache(s) 235 quite frequently. Note that [I-D.ietf-sidrops-8210bis] recommends a 236 polling interval of one hour. This polling timing is conservative 237 because caches can send a Serial Notify PDU to tell routers when 238 there are new data to be fetched. As the RP cache and the router 239 belong to the same operator, routers are free to hammer the RPs as 240 frequently as they wish. 242 A router SHOULD respond with a Serial Query when it receives a Serial 243 Notify from a cache. If a router can not respond appropriately to a 244 Serial Notify, then it MUST send a periodic Serial Query no less 245 frequently than once an hour. 247 6. Effect on Routing 249 Once a router has received an End of Data PDU from a cache, the 250 effect on Route Origin Validation MUST be a matter of seconds to a 251 minute. The router MAY allow incoming VRPs to affect Origin 252 Validation as they arrive instead of waiting for the End of Data PDU. 253 See [I-D.ietf-sidrops-8210bis] for some cautions regarding the 254 arrival and processing sequence of VRPs. 256 7. Alternative Technologies 258 Should the supply chain include components or technologies other than 259 those in IETF documents, the end effect SHOULD be the same; the 260 router(s) SHOULD react to invalid AS origins within the same overall 261 time constraint, one hour, two at most, from ROA creation at the CA 262 publication point to effect in the router. 264 8. Operational Expectations 266 Assuming the above recommendations, in worst conditions such as an 267 RPKI-rtr Notify PDU being ignored, it may take up to two hours for a 268 new ROA to propagate from creation at the CA to BGP speaking routers. 269 Therefore it is RECOMMENDED that planned changes in ROAs take this 270 propagation time into consideration. E.g. if a new route is to be 271 announced in BGP, the operators SHOULD create the ROA around three 272 hours before BGP announcement, or it may not propagate globally. 274 9. Security Considerations 276 Despite common misconceptions and marketing, Route Origin Validation 277 is not a magic security protocol. It is intended to catch 278 operational errors, and is easily gamed and attacked through, for 279 example, AS Path manipulation. It is one tool in the prudent 280 operator's kit, and a good one. 282 If an attacker can add, delete, or modify RPKI data, either in 283 repositories or in flight, they can affect routing and thereby steer 284 or damage traffic. The RPKI system design does much to deter these 285 attacks. But the 'last mile' from the cache to the router uses 286 transport, as opposed to object, security and is vulnerable. This is 287 discussed in [I-D.ietf-sidrops-8210bis]. 289 Similarly, if an attacker can delay prompt propagation of RPKI data 290 on the supply chain described in this document, they can affect 291 routing, and therefore traffic flow, to their advantage. 293 10. IANA Considerations 295 None 297 11. References 299 11.1. Normative References 301 [I-D.ietf-sidrops-8210bis] 302 Bush, R. and R. Austein, "The Resource Public Key 303 Infrastructure (RPKI) to Router Protocol, Version 2", Work 304 in Progress, Internet-Draft, draft-ietf-sidrops-8210bis- 305 05, 22 December 2021, . 308 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 309 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 310 August 1996, . 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, 314 DOI 10.17487/RFC2119, March 1997, 315 . 317 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 318 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 319 DOI 10.17487/RFC4271, January 2006, 320 . 322 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 323 Resource Certificate Repository Structure", RFC 6481, 324 DOI 10.17487/RFC6481, February 2012, 325 . 327 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 328 Origin Authorizations (ROAs)", RFC 6482, 329 DOI 10.17487/RFC6482, February 2012, 330 . 332 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 333 "Manifests for the Resource Public Key Infrastructure 334 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 335 . 337 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 338 Austein, "BGP Prefix Origin Validation", RFC 6811, 339 DOI 10.17487/RFC6811, January 2013, 340 . 342 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 343 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 344 DOI 10.17487/RFC7232, June 2014, 345 . 347 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 348 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 349 May 2017, . 351 [RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication 352 Protocol for the Resource Public Key Infrastructure 353 (RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017, 354 . 356 [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 357 "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, 358 DOI 10.17487/RFC8182, July 2017, 359 . 361 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 362 Infrastructure (RPKI) to Router Protocol, Version 1", 363 RFC 8210, DOI 10.17487/RFC8210, September 2017, 364 . 366 [RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based 367 on Resource Public Key Infrastructure (RPKI)", RFC 8481, 368 DOI 10.17487/RFC8481, September 2018, 369 . 371 11.2. Informative References 373 [I-D.ietf-sidrops-prefer-rrdp] 374 Bruijnzeels, T., Bush, R., and G. Michaelson, "Resource 375 Public Key Infrastructure (RPKI) Repository Requirements", 376 Work in Progress, Internet-Draft, draft-ietf-sidrops- 377 prefer-rrdp-01, 22 October 2021, 378 . 381 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 382 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 383 February 2012, . 385 Appendix A. Acknowledgements 387 The authors wish to thank George Michaelson, Massimiliano Stucchi and 388 Ties de Kock. 390 Authors' Addresses 392 Randy Bush 393 Internet Initiative Japan & Arrcus, Inc. 394 5147 Crystal Springs 395 Bainbridge Island, Washington 98110 396 United States of America 398 Email: randy@psg.com 400 Jay Borkenhagen 401 AT&T 402 200 Laurel Avenue South 403 Middletown, NJ 07748 404 United States of America 406 Email: jayb@att.com 408 Tim Bruijnzeels 409 NLnet Labs 411 Email: tim@nlnetlabs.nl 412 URI: https://www.nlnetlabs.nl/ 413 Job Snijders 414 Fastly 415 Amsterdam 416 Netherlands 418 Email: job@fastly.com