idnits 2.17.1
draft-ietf-sidr-origin-ops-23.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 :
----------------------------------------------------------------------------
== There are 5 instances of lines with private range IPv4 addresses in the
document. If these are generic example addresses, they should be changed
to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x,
198.51.100.x or 203.0.113.x.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords -- however, there's a paragraph with
a matching beginning. Boilerplate error?
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document date (November 21, 2013) is 3771 days in the past. Is this
intentional?
Checking references for intended status: Best Current Practice
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 6490 (Obsoleted by RFC 7730)
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
4 Intended status: Best Current Practice November 21, 2013
5 Expires: May 25, 2014
7 RPKI-Based Origin Validation Operation
8 draft-ietf-sidr-origin-ops-23
10 Abstract
12 Deployment of RPKI-based BGP origin validation has many operational
13 considerations. This document attempts to collect and present those
14 which are most critical. It is expected to evolve as RPKI-based
15 origin validation continues to be deployed and the dynamics are
16 better understood.
18 Requirements Language
20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
22 be interpreted as described in RFC 2119 [RFC2119] only when they
23 appear in all upper case. They may also appear in lower or mixed
24 case as English words, without normative meaning.
26 Status of This Memo
28 This Internet-Draft is submitted in full conformance with the
29 provisions of BCP 78 and BCP 79.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF). Note that other groups may also distribute
33 working documents as Internet-Drafts. The list of current Internet-
34 Drafts is at http://datatracker.ietf.org/drafts/current/.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than as "work in progress."
41 This Internet-Draft will expire on May 25, 2014.
43 Copyright Notice
45 Copyright (c) 2013 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
61 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3
62 3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . 3
63 4. Within a Network . . . . . . . . . . . . . . . . . . . . . . 6
64 5. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 7
65 6. Notes and Recommendations . . . . . . . . . . . . . . . . . . 8
66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
68 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
70 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
71 10.2. Informative References . . . . . . . . . . . . . . . . . 11
72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
74 1. Introduction
76 RPKI-based origin validation relies on widespread deployment of the
77 Resource Public Key Infrastructure (RPKI) [RFC6480]. How the RPKI is
78 distributed and maintained globally is a serious concern from many
79 aspects.
81 While the global RPKI is in the early stages of deployment, there is
82 no single root trust anchor, initial testing is being done by the
83 RIRs, and there are technical testbeds. It is thought that origin
84 validation based on the RPKI will continue to be deployed
85 incrementally over the next few years. It is assumed that eventually
86 there must be a single root trust anchor for the public address
87 space, see [iab].
89 Origin validation needs to be done only by an AS's border routers and
90 is designed so that it can be used to protect announcements which are
91 originated by any network participating in Internet BGP routing:
92 large providers, upstreams and down-streams, and by small stub/
93 enterprise/edge routers.
95 Origin validation has been designed to be deployed on current routers
96 without significant hardware upgrade. It should be used in border
97 routers by operators from large backbones to small stub/entetprise/
98 edge networks.
100 RPKI-based origin validation has been designed so that, with prudent
101 local routing policies, there is little risk that what is seen as
102 today's normal Internet routing is threatened by imprudent deployment
103 of the global RPKI, see Section 5.
105 2. Suggested Reading
107 It is assumed that the reader understands BGP, [RFC4271], the RPKI,
108 see [RFC6480], the RPKI Repository Structure, see [RFC6481], Route
109 Origin Authorizations (ROAs), see [RFC6482], the RPKI to Router
110 Protocol, see [RFC6810], RPKI-based Prefix Validation, see [RFC6811],
111 and Ghostbusters Records, see [RFC6493].
113 3. RPKI Distribution and Maintenance
115 The RPKI is a distributed database containing certificates,
116 Certificate Revocation Lists (CRLs), manifests, ROAs, and
117 Ghostbusters Records as described in [RFC6481]. Policies and
118 considerations for RPKI object generation and maintenance are
119 discussed elsewhere.
121 The RPKI repository design [RFC6481] anticipated a hierarchic
122 organization of repositories, as this seriously improves the
123 performance of relying parties gathering data over a non-hierarchic
124 organization. Publishing parties MUST implement hierarchic directory
125 structures.
127 A local relying party valid cache containing all RPKI data may be
128 gathered from the global distributed database using the rsync
129 protocol, [RFC5781], and a validation tool such as rcynic [rcynic].
131 A validated cache contains all RPKI objects that the RP has verified
132 to be valid according to the rules for validation RPKI certificates
133 and signed objects, see [RFC6487] and [RFC6488]. Entities that trust
134 the cache can use these RPKI objects without further validation.
136 Validated caches may also be created and maintained from other
137 validated caches. Network operators SHOULD take maximum advantage of
138 this feature to minimize load on the global distributed RPKI
139 database. Of course, the recipient relying parties should re-
140 validate the data.
142 As Trust Anchor Locators (TALs), see [RFC6490], are critical to the
143 RPKI trust model, operators should be very careful in their initial
144 selection and vigilant in their maintenance.
146 Timing of inter-cache synchronization, and synchronization between
147 caches and the global RPKI, is outside the scope of this document,
148 and depends on things such as how often routers feed from the caches,
149 how often the operator feels the global RPKI changes significantly,
150 etc.
152 As inter-cache synchronization within an operator's network does not
153 impact global RPKI resources, an operator may choose to synchronize
154 quite frequently.
156 To relieve routers of the load of performing certificate validation,
157 cryptographic operations, etc., the RPKI-Router protocol, [RFC6810],
158 does not provide object-based security to the router. I.e. the
159 router can not validate the data cryptographically from a well-known
160 trust anchor. The router trusts the cache to provide correct data
161 and relies on transport based security for the data received from the
162 cache. Therefore the authenticity and integrity of the data from the
163 cache should be well protected, see Section 7 of [RFC6810].
165 As RPKI-based origin validation relies on the availability of RPKI
166 data, operators SHOULD locate RPKI caches close to routers that
167 require these data and services in order to minimize the impact of
168 likely failures in local routing, intermediate devices, long
169 circuits, etc. One should also consider trust boundaries, routing
170 bootstrap reachability, etc.
172 For example, a router should bootstrap from a chache which is
173 reachable with minimal reliance on other infrastructure such as DNS
174 or routing protocols. If a router needs its BGP and/or IGP to
175 converge for the router to reach a cache, once a cache is reachable,
176 the router will then have to reevaluate prefixes already learned via
177 BGP. Such configurations should be avoided if reasonably possible.
179 If insecure transports are used between an operator's cache and their
180 router(s), the Transport Security recommendations in [RFC6810] SHOULD
181 be followed. In particular, operators MUST NOT use insecure
182 transports between their routers and RPKI caches located in other
183 Autonomous Systems.
185 For redundancy, a router should peer with more than one cache at the
186 same time. Peering with two or more, at least one local and others
187 remote, is recommended.
189 If an operator trusts upstreams to carry their traffic, they may also
190 trust the RPKI data those upstreams cache, and SHOULD peer with
191 caches made available to them by those upstreams. Note that this
192 places an obligation on those upstreams to maintain fresh and
193 reliable caches, and to make them available to their customers. And,
194 as usual, the recipient SHOULD re-validate the data.
196 A transit provider or a network with peers SHOULD validate origins in
197 announcements made by upstreams, down-streams, and peers. They still
198 should trust the caches provided by their upstreams.
200 Before issuing a ROA for a super-block, an operator MUST ensure that
201 all sub-allocations from that block which are announced by other ASs,
202 e.g. customers, have correct ROAs in the RPKI. Otherwise, issuing a
203 ROA for the super-block will cause the announcements of sub-
204 allocations with no ROAs to be viewed as Invalid, see [RFC6811].
205 While waiting for all sub-allocatees to register ROAs, the owner of
206 the super-block may use live BGP data to populate ROAs as a proxy,
207 and then safely issue a ROA for the super-block.
209 Use of RPKI-based origin validation removes any need to originate
210 more specifics into BGP to protect against mis-origination of a less
211 specific prefix. Having a ROA for the covering prefix will protect
212 it.
214 To aid translation of ROAs into efficient search algorithms in
215 routers, ROAs should be as precise as possible, i.e. match prefixes
216 as announced in BGP. E.g. software and operators SHOULD avoid use of
217 excessive max length values in ROAs unless operationally necessary.
219 One advantage of minimal ROA length is that the forged origin attack
220 does not work for sub-prefixes that are not covered by overly long
221 max length. E.g. if, instead of 10.0.0.0/16-24, one issues 10.0.0.0/
222 16 and 10.0.42.0/24, a forged origin attack can not succeed against
223 10.0.666.0/24. They must attack the whole /16, which is more likely
224 to be noticed because of its size.
226 Therefore, ROA generation software MUST use the prefix length as the
227 max length if the user does not specify a max length.
229 RFC EDITOR PLEASE REMOVE THIS PARAGRAPH: The above example does not
230 use a standard documentation prefix as it needs a /16 so that a /24
231 can hole punch. As anything longer than a /24 is not globally
232 routed, a /24 with a /25 (or whatever) hole would not be realistic
233 and the ops reader would spend their energy on that anomaly instead
234 of the example.
236 Operators should be conservative in use of max length in ROAs. E.g.,
237 if a prefix will have only a few sub-prefixes announced, multiple
238 ROAs for the specific announcements should be used as opposed to one
239 ROA with a long max length.
241 Operators owning prefix P should issue ROAs for all ASs which may
242 announce P. If a prefix is legitimately announced by more than one
243 AS, ROAs for all of the ASs SHOULD be issued so that all are
244 considered Valid.
246 In an environment where private address space is announced in eBGP
247 the operator may have private RPKI objects which cover these private
248 spaces. This will require a trust anchor created and owned by that
249 environment, see [I-D.ietf-sidr-ltamgmt].
251 Operators issuing ROAs may have customers which announce their own
252 prefixes and ASs into global eBGP but who do not wish to go though
253 the work to manage the relevant certificates and ROAs. Operators
254 SHOULD offer to provision the RPKI data for these customers just as
255 they provision many other things for them.
257 While an operator using RPKI data MAY choose any polling frequency
258 they wish for ensuring they have a fresh RPKI cache. However, if
259 they use RPKI data as an input to operational routing decisions, they
260 SHOULD ensure local caches inside their AS are synchronized with each
261 other at least every four to six hours.
263 Operators should use tools which warn them of any impending ROA or
264 certificate expiry which could affect the validity of their own data.
265 Ghostbuster Records, see [RFC6493], can be used to facilitate contact
266 with upstream CAs to effect repair.
268 4. Within a Network
270 Origin validation need only be done by edge routers in a network,
271 those which border other networks/ASs.
273 A validating router will use the result of origin validation to
274 influence local policy within its network, see Section 5. In
275 deployment this policy should fit into the AS's existing policy,
276 preferences, etc. This allows a network to incrementally deploy
277 validation-capable border routers.
279 The operator should be aware that RPKI-based origin validation, as
280 any other policy change, can cause traffic shifts in their network.
281 And, as with normal policy shift practice, a prudent operator has
282 tools and methods to predict, measure, modify, etc.
284 5. Routing Policy
286 Origin validation based on the RPKI marks a received announcement as
287 having an origin which is Valid, NotFound, or Invalid, see [RFC6811].
288 How this is used in routing should be specified by the operator's
289 local policy.
291 Local policy using relative preference is suggested to manage the
292 uncertainty associated with a system in early deployment, applying
293 local policy to eliminate the threat of unreachability of prefixes
294 due to ill-advised certification policies and/or incorrect
295 certification data. E.g. until the community feels comfortable
296 relying on RPKI data, routing on Invalid origin validity, though at a
297 low preference, MAY occur.
299 Operators should be aware that accepting Invalid announcements, no
300 matter how de-preffed, will often be the equivalent of treating them
301 as fully Valid. Consider having a ROA for AS 42 for prefix 10.0.0.0/
302 16-24. A BGP announcement for 10.0.666.0/24 from AS 666 would be
303 Invalid. But if policy is not configured to discard it, then longest
304 match forwarding will send packets toward AS 666 no matter the value
305 of local preference.
307 As origin validation will be rolled out incrementally, coverage will
308 be incomplete for a long time. Therefore, routing on NotFound
309 validity state SHOULD be done for a long time. As the transition
310 moves forward, the number of BGP announcements with validation state
311 NotFound should decrease. Hence an operator's policy should not be
312 overly strict, and should prefer Valid announcements, attaching a
313 lower preference to, but still using, NotFound announcements, and
314 dropping or giving a very low preference to Invalid announcements.
315 Merely de-preffing Invalids is ill-advised, see previous paragraph.
317 Some providers may choose to set Local-Preference based on the RPKI
318 validation result. Other providers may not want the RPKI validation
319 result to be more important than AS-path length -- these providers
320 would need to map RPKI validation result to some BGP attribute that
321 is evaluated in BGP's path selection process after AS-path is
322 evaluated. Routers implementing RPKI-based origin validation MUST
323 provide such options to operators.
325 Local-Preference may be used to carry both the validity state of a
326 prefix along with its traffic engineering (TE) characteristic(s). It
327 is likely that an operator already using Local-Preference will have
328 to change policy so they can encode these two separate
329 characteristics in the same BGP attribute without negative impact or
330 opening privilege escalation attacks. E.g. do not encode validation
331 state in higher bits than used for TE.
333 When using a metric which is also influenced by other local policy,
334 an operator should be careful not to create privilege upgrade
335 vulnerabilities. E.g. if Local Pref is set depending on validity
336 state, be careful that peer community signaling SHOULD NOT upgrade an
337 Invalid announcement to Valid or better.
339 Announcements with Valid origins should be preferred over those with
340 NotFound or Invalid origins, if Invalid origins are accepted at all.
342 Announcements with NotFound origins should be preferred over those
343 with Invalid origins.
345 Announcements with Invalid origins SHOULD NOT be used, but may be
346 used to meet special operational needs. In such circumstances, the
347 announcement should have a lower preference than that given to Valid
348 or NotFound.
350 When first deploying origin validation, it may be prudent to not drop
351 announcements with Invalid orgins until inspection of logs, SNMP, or
352 other data indicate that the correct result would be obtained.
354 Validity state signaling SHOULD NOT be accepted from a neighbor AS.
355 The validity state of a received announcement has only local scope
356 due to issues such as scope of trust, RPKI synchrony, and
357 [I-D.ietf-sidr-ltamgmt].
359 6. Notes and Recommendations
361 Like the DNS, the global RPKI presents only a loosely consistent
362 view, depending on timing, updating, fetching, etc. Thus, one cache
363 or router may have different data about a particular prefix than
364 another cache or router. There is no 'fix' for this, it is the
365 nature of distributed data with distributed caches.
367 Operators should beware that RPKI caches are loosely synchronized,
368 even within a single AS. Thus, changes to the validity state of
369 prefixes could be different within an operator's network. In
370 addition, there is no guaranteed interval from when an RPKI cache is
371 updated to when that new information may be pushed or pulled into a
372 set of routers via this protocol. This may result in sudden shifts
373 of traffic in the operator's network, until all of the routers in the
374 AS have reached equilibrium with the validity state of prefixes
375 reflected in all of the RPKI caches.
377 It is hoped that testing and deployment will produce advice on
378 relying party cache loading and timing.
380 There is some uncertainty about the origin AS of aggregates and what,
381 if any, ROA can be used. The long range solution to this is the
382 deprecation of AS-SETs, see [RFC6472].
384 As reliable access to the global RPKI and an operator's caches (and
385 possibly other hosts, e.g. DNS root servers) is important, an
386 operator should take advantage of relying party tools which report
387 changes in BGP or RPKI data which would negatively affect validation
388 of such prefixes.
390 Operators should be aware that there is a trade-off in placement of
391 an RPKI repository in address space for which the repository's
392 content is authoritative. On one hand, an operator will wish to
393 maximize control over the repository. On the other hand, if there
394 are reachability problems to the address space, changes in the
395 repository to correct them may not be easily accessed by others.
397 Operators who manage certificates should associate RPKI Ghostbusters
398 Records (see [RFC6493]) with each publication point they control.
399 These are publication points holding the CRL, ROAs, and other signed
400 objects issued by the operator, and made available to other ASs in
401 support of routing on the public Internet.
403 Routers which perform RPKI-based origin validation must support Four-
404 octet AS Numbers (see [RFC6793]), as, among other things, it is not
405 reasonable to generate ROAs for AS 23456.
407 Software which produces filter lists or other control forms for
408 routers where the target router does not support Four-octet AS
409 Numbers (see [RFC6793]) must be prepared to accept Four-octet AS
410 Numbers and generate the appropriate two-octet output.
412 As a router must evaluate certificates and ROAs which are time
413 dependent, routers' clocks MUST be correct to a tolerance of
414 approximately an hour.
416 Servers should provide time service, such as [RFC5905], to client
417 routers.
419 7. Security Considerations
421 As the BGP origin AS of an update is not signed, origin validation is
422 open to malicious spoofing. Therefore, RPKI-based origin validation
423 is expected to deal only with inadvertent mis-advertisement.
425 Origin validation does not address the problem of AS-Path validation.
426 Therefore paths are open to manipulation, either malicious or
427 accidental.
429 As BGP does not ensure that traffic will flow via the paths it
430 advertises, the data plane may not follow the control plane.
432 Be aware of the class of privilege escalation issues discussed in
433 Section 5 above.
435 8. IANA Considerations
437 This document has no IANA Considerations.
439 9. Acknowledgments
441 The author wishes to thank Shane Amante, Rob Austein, Steve Bellovin,
442 Jay Borkenhagen, Wes George, Seiichi Kawamura, Steve Kent, Pradosh
443 Mohapatra, Chris Morrow, Sandy Murphy, Eric Osterweil, Keyur Patel,
444 Heather and Jason Schiller, John Scudder, Kotikalapudi Sriram,
445 Maureen Stillman, and Dave Ward.
447 10. References
449 10.1. Normative References
451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
452 Requirement Levels", BCP 14, RFC 2119, March 1997.
454 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
455 Resource Certificate Repository Structure", RFC 6481,
456 February 2012.
458 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
459 Origin Authorizations (ROAs)", RFC 6482, February 2012.
461 [RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent,
462 "Resource Public Key Infrastructure (RPKI) Trust Anchor
463 Locator", RFC 6490, February 2012.
465 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
466 Ghostbusters Record", RFC 6493, February 2012.
468 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
469 Autonomous System (AS) Number Space", RFC 6793, December
470 2012.
472 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key
473 Infrastructure (RPKI) to Router Protocol", RFC 6810,
474 January 2013.
476 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
477 Austein, "BGP Prefix Origin Validation", RFC 6811, January
478 2013.
480 10.2. Informative References
482 [I-D.ietf-sidr-ltamgmt]
483 Reynolds, M., Kent, S., and M. Lepinski, "Local Trust
484 Anchor Management for the Resource Public Key
485 Infrastructure", draft-ietf-sidr-ltamgmt-08 (work in
486 progress), April 2013.
488 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
489 Protocol 4 (BGP-4)", RFC 4271, January 2006.
491 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
492 Scheme", RFC 5781, February 2010.
494 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
495 Time Protocol Version 4: Protocol and Algorithms
496 Specification", RFC 5905, June 2010.
498 [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using
499 AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472,
500 December 2011.
502 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
503 Secure Internet Routing", RFC 6480, February 2012.
505 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
506 X.509 PKIX Resource Certificates", RFC 6487, February
507 2012.
509 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
510 Template for the Resource Public Key Infrastructure
511 (RPKI)", RFC 6488, February 2012.
513 [iab] , "IAB statement on the RPKI", , .
517 [rcynic] , "rcynic read-me", , .
519 Author's Address
521 Randy Bush
522 Internet Initiative Japan
523 5147 Crystal Springs
524 Bainbridge Island, Washington 98110
525 US
527 Email: randy@psg.com