-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-ietf-sidrops-prefer-rrdp-01.xml
378 lines (347 loc) · 14.7 KB
/
draft-ietf-sidrops-prefer-rrdp-01.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" category="std" docName="draft-ietf-sidrops-prefer-rrdp-01" updates="6841, 8182">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<front>
<title abbrev="RPKI Repository Requirements">Resource Public Key Infrastructure (RPKI) Repository Requirements</title>
<author initials="T." surname="Bruijnzeels" fullname="Tim Bruijnzeels">
<organization>NLnet Labs</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>tim@nlnetlabs.nl</email>
<uri>https://www.nlnetlabs.nl/</uri>
</address>
</author>
<author initials="R." surname="Bush" fullname="Randy Bush">
<organization>Internet Initiative Japan & Arrcus, Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>randy@psg.com</email>
<uri></uri>
</address>
</author>
<author initials="G." surname="Michaelson" fullname="George Michaelson">
<organization>APNIC</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>ggm@apnic.net</email>
<uri>http://www.apnic.net</uri>
</address>
</author>
<date year="2021" month="October" day="22"/>
<area>Internet</area>
<workgroup></workgroup>
<abstract>
<t>This document formulates a plan of a phased transition to a state where
RPKI repositories and Relying Party software performing RPKI Validation
will use the RPKI Repository Delta Protocol (RRDP) <xref target="RFC8182"/> as the
preferred access protocol, and require rsync as a fallback option only.
</t>
<t>In phase 0, today's deployment, RRDP is supported by most, but not all
Repositories, and most but not all RP software.
</t>
<t>In the proposed phase 1 RRDP will become mandatory to implement for
Repositories, in addition to rsync. This phase can start as soon as
this document is published.
</t>
<t>Phase 2 will start once the proposed updates are implemented by all
compliant Repositories. In this phase RRDP will become mandatory to
implement for all compliant RP software, and rsync will be required
as a fallback option only.
</t>
<t>It should be noted that although this document currently includes
descriptions and updates to RFCs for each of these phases, we may find
that it will be beneficial to have one or more separate documents for
these phases, so that it might be more clear to all when the updates
to RFCs take effect.
</t>
</abstract>
</front>
<middle>
<section anchor="requirements-notation" title="Requirements notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="motivation" title="Motivation">
<t>The Resource Public Key Infrastructure (RPKI) <xref target="RFC6480"/> as originally defined
uses rsync as its distribution protocol, as outlined in <xref target="RFC6481"/>. Later, the
RPKI Repository Delta Protocol (RRDP) <xref target="RFC8182"/> was designed to provide an
alternative. In order to facilitate incremental deployment RRDP has been
deployed as an additional optional protocol, while rsync was still mandatory to
implement.
</t>
<t>While rsync has been very useful in the initial deployment of RPKI, a number of
issues observed with it motivated the design of RRDP, e.g.:
</t>
<t>
<list style="symbols">
<t>rsync is CPU and memory heavy on the server side, and easy to DoS</t>
<t>rsync library support is lacking, complicating RP efficiency and error logging</t>
</list>
</t>
<t>RRDP was designed to leverage HTTPS CDN infrastructure to provide RPKI Repository
content in a resilient way, while reducing the load on the Repository server. It
supports updates being published as atomic deltas, which can help prevent most
of the issues described in section 6 of <xref target="RFC6486"/>.
</t>
<t>For a longer discussion please see section 1 of <xref target="RFC8182"/>.
</t>
<t>In conclusion: we believe that while RRDP is not perfect, and we may indeed
need future work to improve it, it is an improvement over using rsync in the
context of RPKI. Therefore, this document outlines a transition plan where RRDP
becomes mandatory to implement, and the operational dependency on rsync is
reduced to that of a fallback option.
</t>
</section>
<section anchor="plan-to-prefer-rrdp" title="Plan to prefer RRDP">
<t>Changing the RPKI infrastructure to rely on RRDP instead of rsync is a delicate
operation. There is current deployment of Certification Authorities, Repository
Servers and Relying Party software which relies on rsync, and which may not yet
support RRDP.
</t>
<t>Therefore we need to have a plan that ultimately updates the relevant RFCs, but
which uses a phased approach combined with measurements to limit the operational
impact of doing this to (almost) zero.
</t>
<t>The general outline of the plan is as follows. We will describe each step in
more detail below.
</t>
<texttable>
<ttcol align="center">Phase</ttcol>
<ttcol align="center">Description</ttcol>
<c>0</c><c>RPKI repositories support rsync, and optionally RRDP</c>
<c>1</c><c>RPKI repositories support both rsync and RRDP</c>
<c>2</c><c>All RP software prefers RRDP</c>
</texttable>
<section anchor="phase-0--rpki-repositories-support-rsync-and-optionally-rrdp" title="Phase 0 - RPKI repositories support rsync, and optionally RRDP">
<t>This is the situation at the time of writing this document. Relying Parties can
prefer RRDP over rsync today. Therefore all repositories should support RRDP at
their earliest convenience.
</t>
<section anchor="updates-to-rfc-8182" title="Updates to RFC 8182">
<t>Section 3.4.5 of <xref target="RFC8182"/> has the following on "Considerations Regarding
Operational Failures in RRDP":
</t>
<t>Relying Parties could attempt to use alternative repository access
mechanisms, if they are available, according to the accessMethod
element value(s) specified in the SIA of the associated certificate
(see Section 4.8.8 of [RFC6487]).
</t>
<t>The use of the lower case 'could' in this sentence has led some older
versions of RP implementations to conclude that any fallback from RRDP
to rsync as an alternative access mechanism is a local choice. However,
following discussions on this subject it has become clear that there is
a preference to instruct RP software to make use of all possible data
sources. The main motivation being that because of RPKI object security
using a secondary source of data can never lead to a worse outcome in
terms of validation.
</t>
<t>Per this document text mentioned above is replaced by the following:
</t>
<t>Relying Parties MUST attempt to use alternative repository access
mechanisms, if they are available, according to the accessMethod
element value(s) specified in the SIA of the associated certificate
(see Section 4.8.8 of [RFC6487]).
</t>
<t>Note that there is a risk that the rsync repository, as the
alternative access mechanism, becomes overloaded in case all
Relying Parties fall back to it at roughly the same time due
to an issue with RRDP. Therefore it is RECOMMENDED that Relying
Parties use a retry strategy and/or random jitter time before
falling back to rsync. But, the fallback to rsync MUST NOT
be postponed for more than 1 hour.
</t>
</section>
<section anchor="updates-to-rfc-6481" title="Updates to RFC 6481">
<t>Section 3.3 of <xref target="RFC8182"/> stipulates that RRDP files MUST be made
available by repositories which support RRDP. In other words <xref target="RFC8182"/>
expects that RRDP repository availability is treated as a critical
service wherever it is supported.
</t>
<t>Per this document the following bullet point is added to the
considerations listed in in section 3 of <xref target="RFC6481"/>:
</t>
<t>
<list style="symbols">
<t>The publication repository MAY be available using the RPKI
Repository Delta Protocol <xref target="RFC8182"/>. If RPDP is provided,
it SHOULD be hosted on a highly available platform.</t>
</list>
</t>
</section>
</section>
<section anchor="phase-1--rpki-repositories-support-both-rsync-and-rrdp" title="Phase 1 - RPKI repositories support both rsync and RRDP">
<t>During this phase we will make RRDP mandatory to support for Repository Servers,
and measure whether the deployed Repository Servers have been upgraded to do so,
in as far as they don't support RRDP already.
</t>
<section anchor="updates-to-rfc-6481-1" title="Updates to RFC 6481">
<t>In this phase the bullet point update to section 3 of <xref target="RFC6481"/>
mentioned above, where it was said the publication repository MAY
be available using the RPKI Repository Delta Protocol is replaced by:
</t>
<t>
<list style="symbols">
<t>The publication repository MUST be available using the RPKI
Repository Delta Protocol <xref target="RFC8182"/>. The RRDP server SHOULD
be hosted on a highly available platform.</t>
</list>
</t>
</section>
<section anchor="measurements" title="Measurements">
<t>We can find out whether all RPKI repositories support RRDP by running (possibly)
modified Relying Party software that keeps track of this.
</t>
<t>When it is found that Repositories do not yet support RRDP, outreach should be
done to them individually. Since the number of Repositories is fairly low, and
it is in their interest to run RRDP because it addresses availability concerns,
we have confidence that we will find these Repositories willing to make changes.
</t>
</section>
</section>
<section anchor="phase-2--all-rp-software-prefers-rrdp" title="Phase 2 - All RP software prefers RRDP">
<t>Once all Repositories support RRDP we can proceed to make RRDP mandatory to
implement for Relying Party software. But note that RP software is not prohibited
from implementing this support sooner. At the time of this writing all known
RP software supports RRDP, although it is not known to the authors whether all
of them have RRDP enabled and use it as the preferred protocol.
</t>
<section anchor="updates-to-rfc-8182-1" title="Updates to RFC 8182">
<t>From this phase onwards the first paragraph of section 3.4.1 of <xref target="RFC8182"/>
is replaced by the following:
</t>
<t>When a Relying Party performs RPKI validation and learns about a
valid certificate with an SIA entry for the RRDP protocol, it MUST
use this protocol with preference.
</t>
<t>Relying Parties MUST NOT attempt to fetch objects using alternate access
mechanisms, if object retrieval through this protocol is successful.
</t>
<t>However, as stipulated in section 3.4.5, Relying Parties MUST attempt to
use alternative repository access mechanisms, if object retrieval through
RRDP is unsuccessful.
</t>
</section>
<section anchor="measurements-1" title="Measurements">
<t>Although the tools may support RRDP, users will still need to install updated
versions of these tools in their infrastructure. Any Repository operator can
measure this transition by observing access to their RRDP and rsync repositories
respectively.
</t>
<t>But even after new versions have been available, it is expected that there will
be a long, low volume, tail of users who did not upgrade and still depend on rsync.
</t>
</section>
</section>
</section>
<section anchor="appendix--implementation-status" title="Appendix - Implementation Status">
<t>Note that this section is included for tracking purposes during the discussion
phase of this document and is not intended to be included in an RFC.
</t>
<section anchor="current-rrdp-support-in-repository-software" title="Current RRDP Support in Repository Software">
<t>The currently known support for RRDP for repositories is as follows:
</t>
<texttable>
<ttcol align="center">Repository Implementation</ttcol>
<ttcol align="center">Support for RRDP</ttcol>
<c>afrinic</c><c>yes</c>
<c>apnic</c><c>yes</c>
<c>arin</c><c>yes</c>
<c>lacnic</c><c>ongoing</c>
<c>ripe ncc</c><c>yes</c>
<c>Dragon Research Labs</c><c>yes(1,2)</c>
<c>krill</c><c>yes(1)</c>
</texttable>
<t>(1) in use at various National Internet Registries, as well as other resource
holders under RIRs.
(2) not all organizations using this software have upgraded to using RRDP.
</t>
</section>
<section anchor="current-rrdp-support-in-relying-party-software" title="Current RRDP Support in Relying Party software">
<t>All current versions of known Relying Party software support RRDP:
</t>
<texttable>
<ttcol align="center">Relying Party Implementation</ttcol>
<ttcol align="center">support</ttcol>
<ttcol align="center">version</ttcol>
<ttcol align="center">since</ttcol>
<c>DRL</c><c>yes</c><c>?</c><c>?</c>
<c>FORT</c><c>yes</c><c>1.2.0</c><c>02/2021</c>
<c>OctoRPKI</c><c>yes</c><c>1.0.0</c><c>02/2019</c>
<c>Routinator</c><c>yes</c><c>0.6.0</c><c>09/2019</c>
<c>rpki-client</c><c>yes</c><c>0.7.0</c><c>04/2021</c>
<c>RPSTIR2</c><c>yes</c><c>2.0</c><c>04/2020</c>
</texttable>
<t>But, support for RRDP does not necessarily mean that it is also
enabled and preferred over rsync by default. The authors kindly
request that RP implementors provide the following information:
</t>
<texttable>
<ttcol align="center">Relying Party Implementation</ttcol>
<ttcol align="center">prefer</ttcol>
<ttcol align="center">version</ttcol>
<ttcol align="center">since</ttcol>
<c>DRL</c><c>?</c><c>?</c><c>?</c>
<c>FORT</c><c>yes</c><c>?</c><c>?</c>
<c>OctoRPKI</c><c>?</c><c>?</c><c>?</c>
<c>Routinator</c><c>yes</c><c>0.6.0</c><c>09/2019</c>
<c>rpki-client</c><c>?</c><c>?</c><c>?</c>
<c>RPSTIR2</c><c>?</c><c>?</c><c>?</c>
</texttable>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>This document has no IANA actions.
</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>TBD
</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>TBD
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6480.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6481.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6486.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8182.xml"?>
</references>
</back>
</rfc>