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