idnits 2.17.1 draft-ietf-sidr-origin-ops-22.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 (October 07, 2013) is 3853 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 October 07, 2013 5 Expires: April 10, 2014 7 RPKI-Based Origin Validation Operation 8 draft-ietf-sidr-origin-ops-22 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 April 10, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 11 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. 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, CRLs, 116 manifests, ROAs, and Ghostbusters Records as described in [RFC6481]. 117 Policies and considerations for RPKI object generation and 118 maintenance are discussed elsewhere. 120 The RPKI repository design [RFC6481] anticipated an hierarchic 121 organization of repositories, as this seriously affects the 122 performance of relying parties gathering data. Publishing parties 123 SHOULD implement hierarchic directory structures. 125 A local relying party valid cache containing all RPKI data may be 126 gathered from the global distributed database using the rsync 127 protocol, [RFC5781], and a validation tool such as rcynic [rcynic]. 129 Validated caches may also be created and maintained from other 130 validated caches. Network operators SHOULD take maximum advantage of 131 this feature to minimize load on the global distributed RPKI 132 database. Of course, the recipient relying parties SHOULD re- 133 validate the data. 135 As Trust Anchor Locators (TALs), see [RFC6490], are critical to the 136 RPKI trust model, operators should be very careful in their initial 137 selection and vigilant in their maintenance. 139 Timing of inter-cache synchronization, and synchronization between 140 caches and the global RPKI, is outside the scope of this document, 141 and depends on things such as how often routers feed from the caches, 142 how often the operator feels the global RPKI changes significantly, 143 etc. 145 As inter-cache synchronization within an operator's network does not 146 impact global RPKI resources, an operator MAY choose to synchronize 147 quite frequently. 149 To relieve routers of the load of performing certificate validation, 150 cryptographic operations, etc., the RPKI-Router protocol, [RFC6810], 151 does not provide object-based security to the router. I.e. the 152 router can not validate the data cryptographically from a well-known 153 trust anchor. The router trusts the cache to provide correct data 154 and relies on transport based security for the data received from the 155 cache. Therefore the authenticity and integrity of the data from the 156 cache should be well protected, see Section 7 of [RFC6810]. 158 As RPKI-based origin validation relies on the availability of RPKI 159 data, operators SHOULD locate RPKI caches close to routers that 160 require these data and services in order to minimize the impact of 161 likely failures in local routing, intermediate devices, long 162 circuits, etc. One should also consider trust boundaries, routing 163 bootstrap reachability, etc. 165 For example, a router should bootstrap from a chache which is 166 reachable with minimal reliance on other infrastructure such as DNS 167 or routing protocols. If a router needs its BGP and/or IGP to 168 converge for the router to reach a cache, once a cache is reachable, 169 the router will then have to reevaluate prefixes already learned via 170 BGP. Such configurations should be avoided if reasonably possible. 172 If insecure transports are used between an operator's cache and their 173 router(s), the Transport Security recommendations in [RFC6810] SHOULD 174 be followed. In particular, operators MUST NOT use insecure 175 transports between their routers and RPKI caches located in other 176 Autonomous Systems. 178 For redundancy, a router SHOULD peer with more than one cache at the 179 same time. Peering with two or more, at least one local and others 180 remote, is recommended. 182 If an operator trusts upstreams to carry their traffic, they MAY also 183 trust the RPKI data those upstreams cache, and SHOULD peer with 184 caches made available to them by those upstreams. Note that this 185 places an obligation on those upstreams to maintain fresh and 186 reliable caches, and to make them available to their customers. And, 187 as usual, the recipient SHOULD re-validate the data. 189 A transit provider or a network with peers SHOULD validate origins in 190 announcements made by upstreams, down-streams, and peers. They still 191 SHOULD trust the caches provided by their upstreams. 193 Before issuing a ROA for a super-block, an operator MUST ensure that 194 all sub-allocations from that block which are announced by other ASs, 195 e.g. customers, have correct ROAs in the RPKI. Otherwise, issuing a 196 ROA for the super-block will cause the announcements of sub- 197 allocations with no ROAs to be viewed as Invalid, see [RFC6811]. 199 Use of RPKI-based origin validation removes any need to originate 200 more specifics into BGP to protect against mis-origination of a less 201 specific prefix. Having a ROA for the covering prefix will protect 202 it. 204 To aid translation of ROAs into efficient search algorithms in 205 routers, ROAs SHOULD be as precise as possible, i.e. match prefixes 206 as announced in BGP. E.g. software and operators SHOULD avoid use of 207 excessive max length values in ROAs unless operationally necessary. 209 One advantage of minimal ROA length is that the forged origin attack 210 does not work for sub-prefixes that are not covered by overly long 211 max length. E.g. if, instead of 10.0.0.0/16-24, one issues 10.0.0.0/ 212 16 and 10.0.42.0/24, a forged origin attack can not succeed against 213 10.0.66.0/24. They must attack the whole /16, which is more likely 214 to be noticed because of its size. 216 Therefore, ROA generation software MUST use the prefix length as the 217 max length if the user does not specify a max length. 219 RFC EDITOR PLEASE REMOVE THIS PARAGRAPH: The above example does not 220 use a standard documentation prefix as it needs a /16 so that a /24 221 can hole punch. As anything longer than a /24 is not globally 222 routed, a /24 with a /25 (or whatever) hole would not be realistic 223 and the ops reader would spend their energy on that anomaly instead 224 of the example. 226 Operators SHOULD be conservative in use of max length in ROAs. E.g., 227 if a prefix will have only a few sub-prefixes announced, multiple 228 ROAs for the specific announcements SHOULD be used as opposed to one 229 ROA with a long max length. 231 Operators owning prefix P should issue ROAs for all ASs which may 232 announce P. If a prefix is legitimately announced by more than one 233 AS, ROAs for all of the ASs SHOULD be issued so that all are 234 considered Valid. 236 An environment where private address space is announced in eBGP the 237 operator MAY have private RPKI objects which cover these private 238 spaces. This will require a trust anchor created and owned by that 239 environment, see [I-D.ietf-sidr-ltamgmt]. 241 Operators issuing ROAs may have customers which announce their own 242 prefixes and ASs into global eBGP but who do not wish to go though 243 the work to manage the relevant certificates and ROAs. Operators 244 SHOULD offer to provision the RPKI data for these customers just as 245 they provision many other things for them. 247 While an operator using RPKI data MAY choose any polling frequency 248 they wish for ensuring they have a fresh RPKI cache. However, if 249 they use RPKI data as an input to operational routing decisions, they 250 SHOULD ensure local caches inside their AS are synchronized with each 251 other at least every four to six hours. 253 Operators should use tools which warn them of any impending ROA or 254 certificate expiry which could affect the validity of their own data. 255 Ghostbuster Records, see [RFC6493], can be used to facilitate contact 256 with upstream CAs to effect repair. 258 4. Within a Network 260 Origin validation need only be done by edge routers in a network, 261 those which border other networks/ASs. 263 A validating router will use the result of origin validation to 264 influence local policy within its network, see Section 5. In 265 deployment this policy should fit into the AS's existing policy, 266 preferences, etc. This allows a network to incrementally deploy 267 validation-capable border routers. 269 The operator should be aware that RPKI-based origin validation, as 270 any other policy change, can cause traffic shifts in their network. 271 And, as with normal policy shift practice, a prudent operator has 272 tools and methods to predict, measure, modify, etc. 274 5. Routing Policy 276 Origin validation based on the RPKI marks a received announcement as 277 having an origin which is Valid, NotFound, or Invalid, see [RFC6811]. 278 How this is used in routing SHOULD be specified by the operator's 279 local policy. 281 Local policy using relative preference is suggested to manage the 282 uncertainty associated with a system in early deployment, applying 283 local policy to eliminate the threat of unreachability of prefixes 284 due to ill-advised certification policies and/or incorrect 285 certification data. E.g. until the community feels comfortable 286 relying on RPKI data, routing on Invalid origin validity, though at a 287 low preference, MAY occur. 289 Operators should be aware that accepting Invalid announcements, no 290 matter how de-preffed, will often be the equivalent of treating them 291 as fully Valid. Consider having a ROA for AS 42 for prefix 10.0.0.0/ 292 16-24. A BGP announcement for 10.0.666.0/24 from AS 666 would be 293 Invalid. But if policy is not configured to discard it, then longest 294 match forwarding will send packets toward AS 666 no matter the value 295 of local preference. 297 As origin validation will be rolled out incrementally, coverage will 298 be incomplete for a long time. Therefore, routing on NotFound 299 validity state SHOULD be done for a long time. As the transition 300 moves forward, the number of BGP announcements with validation state 301 NotFound should decrease. Hence an operator's policy SHOULD NOT be 302 overly strict, and should prefer Valid announcements, attaching a 303 lower preference to, but still using, NotFound announcements, and 304 dropping or giving a very low preference to Invalid announcements. 305 Merely de-preffing Invalids is ill-advised, see previous paragraph. 307 Some providers may choose to set Local-Preference based on the RPKI 308 validation result. Other providers may not want the RPKI validation 309 result to be more important than AS-path length -- these providers 310 would need to map RPKI validation result to some BGP attribute that 311 is evaluated in BGP's path selection process after AS-path is 312 evaluated. Routers implementing RPKI-based origin validation MUST 313 provide such options to operators. 315 Local-Preference may be used to carry both the validity state of a 316 prefix along with it's traffic engineering characteristic(s). It is 317 likely that an operator already using Local-Preference will have to 318 change policy so they can encode these two separate characteristics 319 in the same BGP attribute without negatively impact or opening 320 privilege escalation attacks. 322 When using a metric which is also influenced by other local policy, 323 an operator should be careful not to create privilege upgrade 324 vulnerabilities. E.g. if Local Pref is set depending on validity 325 state, be careful that peer community signaling SHOULD NOT upgrade an 326 Invalid announcement to Valid or better. 328 Announcements with Valid origins SHOULD be preferred over those with 329 NotFound or Invalid origins, if the latter are accepted at all. 331 Announcements with NotFound origins SHOULD be preferred over those 332 with Invalid origins. 334 Announcements with Invalid origins SHOULD NOT be used, but MAY be 335 used to meet special operational needs. In such circumstances, the 336 announcement SHOULD have a lower preference than that given to Valid 337 or NotFound. 339 When first deploying origin validation, it may be prudent to not drop 340 announcements with Invalid orgins until inspection of logs, SNMP, or 341 other data indicate that the correct result would be obtained. 343 Validity state signaling SHOULD NOT be accepted from a neighbor AS. 344 The validity state of a received announcement has only local scope 345 due to issues such as scope of trust, RPKI synchrony, and 346 [I-D.ietf-sidr-ltamgmt]. 348 6. Notes 350 Like the DNS, the global RPKI presents only a loosely consistent 351 view, depending on timing, updating, fetching, etc. Thus, one cache 352 or router may have different data about a particular prefix than 353 another cache or router. There is no 'fix' for this, it is the 354 nature of distributed data with distributed caches. 356 Operators should beware that RPKI caches are loosely synchronized, 357 even within a single AS. Thus, changes to the validity state of 358 prefixes could be different within an operator's network. In 359 addition, there is no guaranteed interval from when an RPKI cache is 360 updated to when that new information may be pushed or pulled into a 361 set of routers via this protocol. This may result in sudden shifts 362 of traffic in the operator's network, until all of the routers in the 363 AS have reached equilibrium with the validity state of prefixes 364 reflected in all of the RPKI caches. 366 It is hoped that testing and deployment will produce advice on 367 relying party cache loading and timing. 369 There is some uncertainty about the origin AS of aggregates and what, 370 if any, ROA can be used. The long range solution to this is the 371 deprecation of AS-SETs, see [RFC6472]. 373 As reliable access to the global RPKI and an operator's caches (and 374 possibly other hosts, e.g. DNS root servers) is important, an 375 operator SHOULD take advantage of relying party tools which report 376 changes in BGP or RPKI data which would negatively affect validation 377 of such prefixes. 379 Operators should be aware that there is a trade-off in placement of 380 an RPKI repository in address space for which the repository's 381 content is authoritative. On one hand, an operator will wish to 382 maximize control over the repository. On the other hand, if there 383 are reachability problems to the address space, changes in the 384 repository to correct them may not be easily accessed by others. 386 Operators who manage certificates SHOULD associate RPKI Ghostbusters 387 Records (see [RFC6493]) with each publication point they control. 388 These are publication points holding the CRL, ROAs, and other signed 389 objects issued by the operator, and made available to other ASs in 390 support of routing on the public Internet. 392 Routers which perform RPKI-based origin validation must support Four- 393 octet AS Numbers (see [RFC6793]), as, among other things, it is not 394 reasonable to generate ROAs for AS 23456. 396 Software which produces filter lists or other control forms for 397 routers where the target router does not support Four-octet AS 398 Numbers (see [RFC6793]) must be prepared to accept Four-octet AS 399 Numbers and generate the appropriate two-octet output. 401 As a router must evaluate certificates and ROAs which are time 402 dependent, routers' clocks MUST be correct to a tolerance of 403 approximately an hour. 405 Servers should provide time service, such as [RFC5905], to client 406 routers. 408 7. Security Considerations 410 As the BGP origin AS of an update is not signed, origin validation is 411 open to malicious spoofing. Therefore, RPKI-based origin validation 412 is expected to deal only with inadvertent mis-advertisement. 414 Origin validation does not address the problem of AS-Path validation. 415 Therefore paths are open to manipulation, either malicious or 416 accidental. 418 As BGP does not ensure that traffic will flow via the paths it 419 advertises, the data plane may not follow the control plane. 421 Be aware of the class of privilege escalation issues discussed in 422 Section 5 above. 424 8. IANA Considerations 426 This document has no IANA Considerations. 428 9. Acknowledgments 430 The author wishes to thank Shane Amante, Rob Austein, Steve Bellovin, 431 Jay Borkenhagen, Wes George, Seiichi Kawamura, Steve Kent, Pradosh 432 Mohapatra, Chris Morrow, Sandy Murphy, Eric Osterweil, Keyur Patel, 433 Heather and Jason Schiller, John Scudder, Kotikalapudi Sriram, 434 Maureen Stillman, and Dave Ward. 436 10. References 438 10.1. Normative References 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, March 1997. 443 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 444 Resource Certificate Repository Structure", RFC 6481, 445 February 2012. 447 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 448 Origin Authorizations (ROAs)", RFC 6482, February 2012. 450 [RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 451 "Resource Public Key Infrastructure (RPKI) Trust Anchor 452 Locator", RFC 6490, February 2012. 454 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 455 Ghostbusters Record", RFC 6493, February 2012. 457 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 458 Autonomous System (AS) Number Space", RFC 6793, December 459 2012. 461 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 462 Infrastructure (RPKI) to Router Protocol", RFC 6810, 463 January 2013. 465 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 466 Austein, "BGP Prefix Origin Validation", RFC 6811, January 467 2013. 469 10.2. Informative References 471 [I-D.ietf-sidr-ltamgmt] 472 Reynolds, M., Kent, S., and M. Lepinski, "Local Trust 473 Anchor Management for the Resource Public Key 474 Infrastructure", draft-ietf-sidr-ltamgmt-08 (work in 475 progress), April 2013. 477 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 478 Protocol 4 (BGP-4)", RFC 4271, January 2006. 480 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 481 Scheme", RFC 5781, February 2010. 483 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 484 Time Protocol Version 4: Protocol and Algorithms 485 Specification", RFC 5905, June 2010. 487 [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using 488 AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, 489 December 2011. 491 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 492 Secure Internet Routing", RFC 6480, February 2012. 494 [rcynic] , "rcynic read-me", , 495 . 497 Author's Address 499 Randy Bush 500 Internet Initiative Japan 501 5147 Crystal Springs 502 Bainbridge Island, Washington 98110 503 US 505 Email: randy@psg.com