idnits 2.17.1 draft-ietf-sidrops-rpki-rov-timing-03.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 (March 25, 2021) is 1121 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-00 ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) Summary: 1 error (**), 0 flaws (~~), 2 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: September 26, 2021 AT&T 6 T. Bruijnzeels 7 NLnet Labs 8 J. Snijders 9 Fastly 10 March 25, 2021 12 Timing Parameters in the RPKI based Route Origin Validation Supply Chain 13 draft-ietf-sidrops-rpki-rov-timing-03 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 September 26, 2021. 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 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Certification Authority Publishing . . . . . . . . . . . . . 4 66 4. Relying Party Fetching . . . . . . . . . . . . . . . . . . . 4 67 5. Router Updating . . . . . . . . . . . . . . . . . . . . . . . 5 68 6. Effect on Routing . . . . . . . . . . . . . . . . . . . . . . 5 69 7. Alternative Technologies . . . . . . . . . . . . . . . . . . 5 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 10.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 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 published by a distributed set of Certification Authorities (CAs) 90 at the IANA, RIRs, NIRs, and ISPs (see [RFC6481]). 92 Publication Points: The CAs publish their authoritative data in 93 publicly accessible repositories which have a Publication Point 94 (PP) for each CA. 96 Relying Parties: Relying Parties are a local (to the routers) set of 97 one or more collected and verified caches of RPKI data which the 98 RPs collect from the PPs. 100 Currently RPs can pull from other RPs, thereby allowing a somewhat 101 complex topology. 103 Routers: Validating routers fetch data from local RP caches using 104 the RPKI to Router Protocol, [I-D.ietf-sidrops-8210bis]. Routers 105 are clients of the caches. Validating routers MUST have a trust 106 relationship with, and a trusted transport channel to, any RP(s) 107 they use. [I-D.ietf-sidrops-8210bis] specifies mechanisms for a 108 router to assure itself of the authenticity of the cache(s) and to 109 authenticate itself to cache(s). 111 As Resource Public Key Infrastructure based Route Origin Validation 112 (ROV) becomes deployed in the Internet, the quality of the routing 113 control plane, and hence timely and accurate delivery of packets in 114 the data plane, increasingly depend on prompt and accurate 115 propagation of the RPKI data from the originating Certification 116 Authorities (CAs), to Relying Parties (RPs), to Border Gateway 117 Protocol (BGP) speaking routers. 119 Origin Validation based on stale ROAs allows accidental or 120 intentional mis-origination; announcement of a prefix by an AS which 121 does not have the authority to do so. While delays in ROA 122 propagation to ROV in routers can cause loss of good traffic. 123 Therefore minimizing propagation time of data from CAs to routers is 124 important. 126 Before the data can start on the CA to router supply chain, the 127 resource holder (operator) MUST create or delete the relevant ROA(s) 128 through the CA's operational interface(s). The operator is 129 responsible for anticipating their future needs for ROAs, be aware of 130 the propagation time from creating ROAs to effect on routing, and 131 SHOULD create, delete, or modify ROAs sufficiently in advance of any 132 needs in the routing system. 134 There are questions of how frequently a CA publishes, how often an RP 135 pulls, and how often routers pull from their RP(s). Overall, the 136 router(s) SHOULD react within an hour of ROA publication. 138 For CAs publishing to PPs, a few seconds to a minute seems easily 139 achieved with reasonable software. See Section 3. 141 Relying Party validating caches periodically retrieve data from CA 142 publication points. RPs using rsync to poll publication points every 143 ten minutes would be a burden today, given the load it would put on 144 publication services, cf. one notorious repository which was 145 structured against specification. RPs using RRDP impose less load. 146 As the infrastructure moves from rsync to RRDP 147 [I-D.sidrops-bruijnzeels-deprecate-rsync], RRDP is designed for quite 148 frequent polling as long as Relying Parties use the "If-Modified- 149 Since" header and there is a caching infrastructure. For rsync, an 150 hour would be the longest acceptable window and half an hour the 151 shortest. See Section 4. 153 For BGP speaking router(s) pulling from the RP(s), five minutes to an 154 hour is a wide window. But, the RPKI-Rtr protocol does have the 155 Serial Notify PDU, the equivalent of DNS Notify, where the cache 156 tells the router that it has new data. See Section 5. 158 We discuss each of these in detail below. 160 2. Related Work 162 It is assumed that the reader understands BGP, [RFC4271], the RPKI 163 [RFC6480], RPKI Manifests [RFC6486], Route Origin Authorizations 164 (ROAs), [RFC6482], the RPKI Repository Delta Protocol (RRDP) 165 [RFC8182], The Resource Public Key Infrastructure (RPKI) to Router 166 Protocol [I-D.ietf-sidrops-8210bis], RPKI-based Prefix Validation, 167 [RFC6811], and Origin Validation Clarifications, [RFC8481]. 169 3. Certification Authority Publishing 171 A principal constraint on publication timing is ensuring the CRL and 172 Manifest ([RFC6486]) are atomically correct with respect to the other 173 repository data. With rsync, the publication point must be 174 atomically correct before it becomes current. RRDP ([RFC8182]) is 175 similar, the publication point must be atomically correct before it 176 is published. 178 4. Relying Party Fetching 180 rsync puts a load on RPKI publication point servers. Therefore 181 relying party caches have been discouraged from fetching more 182 frequently than on the order of a half hour. Times as long as a day 183 were even suggested. We conclude that RPs using rsync SHOULD pull 184 from CA publication points once an hour. 186 With RRDP ([RFC8182]), such constraints are less relevant. [RFC8182] 187 makes clear that polling as frequently as a few seconds is acceptable 188 iff Relying Parties use the "If-Modified-Since" header and there is 189 caching. In such circumstances, the RRDP polling interval MUST be no 190 more than ten minutes. 192 Migration from rsync to RRDP in 193 [I-D.sidrops-bruijnzeels-deprecate-rsync] is recommended. During 194 dual RRDP/rsync operation, should an RP need to fall over from RRDP 195 to rsync, a jittered delay with a mean of 15 minutes is recommended. 197 A number of timers are embedded in the X.509 RPKI data which should 198 also be considered. E.g., CRL publication commitments, expiration of 199 EE certificates pointing to Manifests, and the Manifests themselves. 200 Some CA operators commonly indicate new CRL information should be 201 available in the next 24 hours. These 24-hour sliding timers, if 202 combined with fetching RPKI data once a day, would cause needless 203 brittleness in the face of transient network issues between the CA 204 and RP. 206 5. Router Updating 208 The rate of change of ROA data is estimated to remain small, on the 209 order of a few ROAs a minute, but with bursts. Therefore, the 210 routers may update from the (presumed local) relying party cache(s) 211 quite frequently. Note that [I-D.ietf-sidrops-8210bis] recommends a 212 polling interval of one hour. This polling timing is conservative 213 because caches can send a Serial Notify PDU to tell routers when 214 there are new data to be fetched. As the RP cache and the router 215 belong to the same operator, routers are free to hammer the RPs as 216 much as they wish. 218 A router SHOULD respond with a Serial Query when it receives a Serial 219 Notify from a cache. If a router can not respond appropriately to a 220 Serial Notify, then it MUST send a periodic Serial Query no less 221 frequently than once an hour. 223 6. Effect on Routing 225 Once a router has received an End of Data PDU from a cache, the 226 effect on Route Origin Validation MUST be a matter of seconds to a 227 minute. The router MAY allow incoming VRPs to affect Origin 228 Validation as they arrive instead of waiting for the End of Data PDU. 229 See [I-D.ietf-sidrops-8210bis] for some cautions regarding the 230 arrival sequence of VRPs. 232 7. Alternative Technologies 234 Should the supply chain include components or technologies other than 235 those in IETF documents, the end effect SHOULD be the same; the 236 router(s) SHOULD react to invalid AS origins within the same overall 237 time constraint, an hour at most from ROA creation at the CA 238 publication point to effect in the router. 240 8. Security Considerations 242 Despite common misconceptions and marketing, Route Origin Validation 243 is not a security protocol. It is intended to catch operational 244 errors, and is easily gamed and attacked. 246 If an attacker can add, delete, or modify RPKI data, either in 247 repositories or in flight, they can affect routing and thereby steer 248 or damage traffic. The RPKI system design does much to deter these 249 attacks. But the 'last mile' from the cache to the router uses 250 transport, as opposed to object, security and is vulnerable. This is 251 discussed in [I-D.ietf-sidrops-8210bis]. 253 Similarly, if an attacker can delay prompt propagation of RPKI data 254 on the supply chain described in this document, they can affect 255 routing, and therefore traffic flow, to their advantage. 257 9. IANA Considerations 259 None 261 10. References 263 10.1. Normative References 265 [I-D.ietf-sidrops-8210bis] 266 Bush, R. and R. Austein, "The Resource Public Key 267 Infrastructure (RPKI) to Router Protocol, Version 2", 268 draft-ietf-sidrops-8210bis-00 (work in progress), March 269 2020. 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, 273 DOI 10.17487/RFC2119, March 1997, 274 . 276 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 277 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 278 DOI 10.17487/RFC4271, January 2006, 279 . 281 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 282 Resource Certificate Repository Structure", RFC 6481, 283 DOI 10.17487/RFC6481, February 2012, 284 . 286 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 287 Origin Authorizations (ROAs)", RFC 6482, 288 DOI 10.17487/RFC6482, February 2012, 289 . 291 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 292 "Manifests for the Resource Public Key Infrastructure 293 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 294 . 296 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 297 Austein, "BGP Prefix Origin Validation", RFC 6811, 298 DOI 10.17487/RFC6811, January 2013, 299 . 301 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 302 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 303 May 2017, . 305 [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 306 "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, 307 DOI 10.17487/RFC8182, July 2017, 308 . 310 [RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based 311 on Resource Public Key Infrastructure (RPKI)", RFC 8481, 312 DOI 10.17487/RFC8481, September 2018, 313 . 315 10.2. Informative References 317 [I-D.sidrops-bruijnzeels-deprecate-rsync] 318 Bruijnzeels, T., Bush, R., and G. Michaelson, "Resource 319 Public Key Infrastructure (RPKI) Repository Requirements", 320 draft-sidrops-bruijnzeels-deprecate-rsync-01 (work in 321 progress), April 2020. 323 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 324 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 325 February 2012, . 327 Appendix A. Acknowledgements 329 The authors wish to thank Massimiliano Stucchi. 331 Authors' Addresses 333 Randy Bush 334 Internet Initiative Japan & Arrcus, Inc. 335 5147 Crystal Springs 336 Bainbridge Island, Washington 98110 337 United States of America 339 Email: randy@psg.com 341 Jay Borkenhagen 342 AT&T 343 200 Laurel Avenue South 344 Middletown, NJ 07748 345 United States of America 347 Email: jayb@att.com 349 Tim Bruijnzeels 350 NLnet Labs 352 Email: tim@nlnetlabs.nl 353 URI: https://www.nlnetlabs.nl/ 355 Job Snijders 356 Fastly 357 Amsterdam 358 Netherlands 360 Email: job@fastly.com