idnits 2.17.1 draft-ymbk-rpki-rov-timing-00.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 (April 21, 2020) is 1466 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. Snijders 5 Expires: October 23, 2020 NTT 6 April 21, 2020 8 Timing Parameters in the RPKI based Route Origin Validation Supply Chain 9 draft-ymbk-rpki-rov-timing-00 11 Abstract 13 This document explores, and makes recommendations for, timing of 14 Resource Public Key Infrastructure publication, propagation, and use 15 of RPKI ROV data in relying parties and routers. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 21 "OPTIONAL" in this document are to be interpreted as described in BCP 22 14 [RFC2119] [RFC8174] when, and only when, they appear in all 23 capitals, as shown here. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 23, 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Deployment Structure . . . . . . . . . . . . . . . . . . . . 3 62 4. Certification Authority Publishing . . . . . . . . . . . . . 4 63 5. Replying Party Fetching . . . . . . . . . . . . . . . . . . . 4 64 6. Router Updating . . . . . . . . . . . . . . . . . . . . . . . 4 65 7. Alternative Technologies . . . . . . . . . . . . . . . . . . 4 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 10.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 As Resource Public Key Infrastructure (RPKI) based Route Origin 77 Validation (ROV) becomes deployed in the Internet, the quality of the 78 routing control plane, and hence timely and accurate delivery of 79 packets in the data plane, depend more and more on prompt and 80 accurate propagation of the RPKI data from the originating 81 Certification Authorities (CAs), to Relying Parties (RPs), to 82 External Border Gateway Protocol (eBGP) speaking routers. 84 Origination Validation based on stale ROAs allows accidental mis- 85 origination. While delayed ROA propagation to ROV in routers can 86 cause loss of good traffic. Though it may not be reasonable today, 87 services such as DDoS cleaners would prefer that ROA publication had 88 almost immediate effect on routing. 90 This draft is an exploration of, and recommendations for, timing of 91 Resource Public Key Infrastructure publication, propagation, and use 92 in relying party caches and routers. 94 There are the questions of how frequently a CA publishes, how often 95 an RP pulls, and how often routers pull from their RP(s). Overall, 96 the router(s) SHOULD react within an hour of to ROA publication. 98 For CAs publishing, a few seconds to a minute seems easily achieved 99 with reasonable software. See Section 4. 101 Relying Party validating caches periodically retrieve data from CA 102 publication points.. RPs using rcynic to poll publication points 103 every ten minutes would be a burden today, given the load it will put 104 on publication services, and one notorious repository which is 105 against specification. But RPs using RRDP impose no such load. So 106 as the infrastructure moves from rcynic to RRDP, fetching every ten 107 minutes would be reasonable. For rcynic, an hour would be the 108 longest acceptable window. See Section 5. 110 For the BGP speaking router(s) pulling from the RP(s), five minutes 111 to an hour is a wide window. But, the RPKI-Rtr protocol does have 112 the Serial Notify PDU, the equivalent of DNS Notify, where the cache 113 tells the router that it has new data. See Section 6. 115 We discuss each of these in detail below. 117 2. Related Work 119 It is assumed that the reader understands BGP, [RFC4271], the RPKI 120 [RFC6480], RPKI Manifests [RFC6486], Route Origin Authorizations 121 (ROAs), [RFC6482], the RPKI Repository Delta Protocol (RRDP) 122 [RFC8182], The Resource Public Key Infrastructure (RPKI) to Router 123 Protocol [I-D.ietf-sidrops-8210bis], RPKI-based Prefix Validation, 124 [RFC6811], and Origin Validation Clarifications, [RFC8481]. 126 3. Deployment Structure 128 Deployment of the RPKI to reach routers has a three-level structure 129 as follows: 131 Cerification Authorities: The authoritative data of the RPKI are 132 published in a distributed set of servers, Certification 133 Authorities, at the IANA, RIRs, NIRs, and ISPs (see [RFC6481]). 135 Relying Parties: Relying Parties are a local set of one or more 136 collected and verified caches of RPKI data. A Relying Party, 137 e.g., router or other client, MUST have a trust relationship with, 138 and a trusted transport channel to, any RP(s) it uses. 140 Note that RPs can pull from other RPs, thereby creating a somewhat 141 complex topology. 143 Routers: A router fetches data from a local cache using the RPKI to 144 Router Protocol described in [I-D.ietf-sidrops-8210bis]. It is 145 said to be a client of the cache. There are mechanisms for the 146 router to assure itself of the authenticity of the cache and to 147 authenticate itself to the cache. 149 4. Certification Authority Publishing 151 A principal constraint on publication timing is ensuring the CRL and 152 Manifest ([RFC6486]) are atomically correct with respect to the other 153 repository data. With rcynic, the directory must be atomically 154 correct before it becomes current. RRDP ([RFC8182]) is similar, the 155 directory must be atomically correct before it is published. 157 5. Replying Party Fetching 159 rcynic puts a load on RPKI publication point servers. Therefore 160 relying party caches have been discouraged from fetching more 161 frequently than on the order of an hour. Times as long as a day were 162 even suggested. With RRDP ([RFC8182]), these constraints are no 163 longer relevant. 165 A number of timers are embedded in the X.509 RPKI data which should 166 also be considered. E.g., CRL publication commitments, expiration of 167 EE certificates pointing to Manifests and the Manifests themselves. 168 Some CA operators commonly indicate new CRL information should be 169 available in the next 24 hours. These 24-hour sliding timers, 170 combined with fetching RPKI data once a day, cause needless 171 brittleness in the face of transient network issues between the CA 172 and RP. 174 6. Router Updating 176 The rate of change of ROA data can be estimated to remain small, 177 maybe on the order of a few ROAs a minute, but with bursts. 178 Therefore, the routers may update from the (presumed local) relying 179 party cache(s) quite frequently. Note that 180 [I-D.ietf-sidrops-8210bis] recommends a polling interval of one hour. 181 This conservative timing is because caches can send a Serial Notify 182 PDU to tell routers when there are new data to be fetched. 184 A router SHOULD respond with a Serial Query when it receives a Serial 185 Notify from a cache. If a router can not respond to a Serial Notify, 186 then it MUST send a periodic Serial Query no less frequently than 187 once an hour. 189 7. Alternative Technologies 191 Should the supply chain include components or technologies other than 192 those in IETF documents, the end effect SHOULD be the same; the 193 router(s) SHOULD react to invalid AS origins within the same overall 194 time constraint, an hour at most from ROA creation at the CA 195 publication point to effect in the router. 197 8. Security Considerations 199 Route Origin Validation is not a security protocol. It is intended 200 to catch operational errors, and is easily gamed and attacked. 202 9. IANA Considerations 204 None 206 10. References 208 10.1. Normative References 210 [I-D.ietf-sidrops-8210bis] 211 Bush, R. and R. Austein, "The Resource Public Key 212 Infrastructure (RPKI) to Router Protocol, Version 2", 213 draft-ietf-sidrops-8210bis-00 (work in progress), March 214 2020. 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, 218 DOI 10.17487/RFC2119, March 1997, 219 . 221 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 222 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 223 DOI 10.17487/RFC4271, January 2006, 224 . 226 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 227 Resource Certificate Repository Structure", RFC 6481, 228 DOI 10.17487/RFC6481, February 2012, 229 . 231 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 232 Origin Authorizations (ROAs)", RFC 6482, 233 DOI 10.17487/RFC6482, February 2012, 234 . 236 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 237 "Manifests for the Resource Public Key Infrastructure 238 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 239 . 241 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 242 Austein, "BGP Prefix Origin Validation", RFC 6811, 243 DOI 10.17487/RFC6811, January 2013, 244 . 246 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 247 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 248 May 2017, . 250 [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 251 "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, 252 DOI 10.17487/RFC8182, July 2017, 253 . 255 [RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based 256 on Resource Public Key Infrastructure (RPKI)", RFC 8481, 257 DOI 10.17487/RFC8481, September 2018, 258 . 260 10.2. Informative References 262 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 263 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 264 February 2012, . 266 Appendix A. Acknowledgements 268 The authors wish to thank Massimiliano Stucchi. 270 Authors' Addresses 272 Randy Bush 273 Internet Initiative Japan & Arrcus, Inc. 274 5147 Crystal Springs 275 Bainbridge Island, Washington 98110 276 United States of America 278 Email: randy@psg.com 280 Job Snijders 281 NTT Ltd. 282 Theodorus Majofskistraat 100 283 Amsterdam 1065 SZ 284 The Netherlands 286 Email: job@ntt.net