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