idnits 2.17.1 draft-ietf-sidr-origin-ops-20.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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: When using a metric which is also influenced by other local policy, an operator should be careful not to create privilege upgrade vulnerabilities. E.g. if Local Pref is set depending on validity state, be careful that peer community signaling MAY NOT upgrade an Invalid announcement to Valid or better. -- The document date (February 21, 2013) is 4081 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) == Outdated reference: A later version (-08) exists of draft-ietf-sidr-ltamgmt-07 ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) ** Downref: Normative reference to an Informational RFC: RFC 5781 ** Downref: Normative reference to an Informational RFC: RFC 6480 ** Obsolete normative reference: RFC 6490 (Obsoleted by RFC 7730) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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 February 21, 2013 5 Expires: August 25, 2013 7 RPKI-Based Origin Validation Operation 8 draft-ietf-sidr-origin-ops-20 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 August 25, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . 10 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 190 of excessive max length values in ROAs unless operationally 191 necessary. 193 One advantage of minimal ROA length is that the forged origin attack 194 does not work for sub-prefixes that are not covered by overly long 195 max length. E.g. if, instead of 10.0.0.0/16-24, one issues 10.0.0.0 196 /16 and 10.0.42.0/24, a forged origin attack can not succeed against 197 10.0.66.0/24. They must attack the whole /16, which is more likely 198 to be noticed because of its size. 200 Therefore, ROA generation software MUST use the prefix length as the 201 max length if the user does not specify a max length. 203 Operators SHOULD be conservative in use of max length in ROAs. E.g., 204 if a prefix will have only a few sub-prefixes announced, multiple 205 ROAs for the specific announcements SHOULD be used as opposed to one 206 ROA with a long max length. 208 Operators owning prefix P should issue ROAs for all ASs which may 209 announce P. If a prefix is legitimately announced by more than one 210 AS, ROAs for all of the ASs SHOULD be issued so that all are 211 considered Valid. 213 An environment where private address space is announced in eBGP the 214 operator MAY have private RPKI objects which cover these private 215 spaces. This will require a trust anchor created and owned by that 216 environment, see [I-D.ietf-sidr-ltamgmt]. 218 Operators issuing ROAs may have customers which announce their own 219 prefixes and ASs into global eBGP but who do not wish to go though 220 the work to manage the relevant certificates and ROAs. Operators 221 SHOULD offer to provision the RPKI data for these customers just as 222 they provision many other things for them. 224 While an operator using RPKI data MAY choose any polling frequency 225 they wish for ensuring they have a fresh RPKI cache. However, if 226 they use RPKI data as an input to operational routing decisions, they 227 SHOULD ensure local caches inside their AS are synchronized with each 228 other at least every four to six hours. 230 Operators should use tools which warn them of any impending ROA or 231 certificate expiry which could affect the validity of their own data. 232 Ghostbuster Records, see [RFC6493], can be used to facilitate contact 233 with upstream CAs to effect repair. 235 4. Within a Network 237 Origin validation need only be done by edge routers in a network, 238 those which border other networks/ASs. 240 A validating router will use the result of origin validation to 241 influence local policy within its network, see Section 5. In 242 deployment this policy should fit into the AS's existing policy, 243 preferences, etc. This allows a network to incrementally deploy 244 validation-capable border routers. 246 The operator should be aware that RPKI-based origin validation, as 247 any other policy change, can cause traffic shifts in their network. 248 And, as with normal policy shift practice, a prudent operator has 249 tools and methods to predict, measure, modify, etc. 251 5. Routing Policy 253 Origin validation based on the RPKI marks a received announcement as 254 having an origin which is Valid, NotFound, or Invalid, see [RFC6811]. 255 How this is used in routing SHOULD be specified by the operator's 256 local policy. 258 Local policy using relative preference is suggested to manage the 259 uncertainty associated with a system in early deployment, applying 260 local policy to eliminate the threat of unreachability of prefixes 261 due to ill-advised certification policies and/or incorrect 262 certification data. E.g. until the community feels comfortable 263 relying on RPKI data, routing on Invalid origin validity, though at a 264 low preference, MAY occur. 266 Operators should be aware that accepting Invalid announcements, no 267 matter how de-preffed, will often be the equivalent of treating them 268 as fully Valid. Consider having a ROA for AS 42 for prefix 10.0.0.0/ 269 16-24. A BGP announcement for 10.0.666.0/24 from AS 666 would be 270 Invalid. But if policy is not configured to discard it, then longest 271 match forwarding will send packets to AS 666 no matter the value of 272 local preference. 274 As origin validation will be rolled out incrementally, coverage will 275 be incomplete for a long time. Therefore, routing on NotFound 276 validity state SHOULD be done for a long time. As the transition 277 moves forward, the number of BGP announcements with validation state 278 NotFound should decrease. Hence an operator's policy SHOULD NOT be 279 overly strict, and should prefer Valid announcements, attaching a 280 lower preference to, but still using, NotFound announcements, and 281 dropping or giving a very low preference to Invalid announcements. 283 Some providers may choose to set Local-Preference based on the RPKI 284 validation result. Other providers may not want the RPKI validation 285 result to be more important than AS-path length -- these providers 286 would need to map RPKI validation result to some BGP attribute that 287 is evaluated in BGP's path selection process after AS-path is 288 evaluated. Routers implementing RPKI-based origin validation MUST 289 provide such options to operators. 291 Local-Preference may be used to carry both the validity state of a 292 prefix along with it's traffic engineering characteristic(s). It is 293 likely that an operator already using Local-Preference will have to 294 change policy so they can encode these two separate characteristics 295 in the same BGP attribute without negatively impact or opening 296 privilege escalation attacks. 298 When using a metric which is also influenced by other local policy, 299 an operator should be careful not to create privilege upgrade 300 vulnerabilities. E.g. if Local Pref is set depending on validity 301 state, be careful that peer community signaling MAY NOT upgrade an 302 Invalid announcement to Valid or better. 304 Announcements with Valid origins SHOULD be preferred over those with 305 NotFound or Invalid origins, if the latter are accepted at all. 307 Announcements with NotFound origins SHOULD be preferred over those 308 with Invalid origins. 310 Announcements with Invalid origins SHOULD NOT be used, but MAY be 311 used to meet special operational needs. In such circumstances, the 312 announcement SHOULD have a lower preference than that given to Valid 313 or NotFound. 315 When first deploying origin validation, it may be prudent to not drop 316 announcements with Invalid orgins until inspection of logs, SNMP, or 317 other data indicate that the correct result would be obtained. 319 Validity state signaling SHOULD NOT be accepted from a neighbor AS. 320 The validity state of a received announcement has only local scope 321 due to issues such as scope of trust, RPKI synchrony, and 322 [I-D.ietf-sidr-ltamgmt]. 324 6. Notes 326 Like the DNS, the global RPKI presents only a loosely consistent 327 view, depending on timing, updating, fetching, etc. Thus, one cache 328 or router may have different data about a particular prefix than 329 another cache or router. There is no 'fix' for this, it is the 330 nature of distributed data with distributed caches. 332 Operators should beware that RPKI caches are loosely synchronized, 333 even within a single AS. Thus, changes to the validity state of 334 prefixes could be different within an operator's network. In 335 addition, there is no guaranteed interval from when an RPKI cache is 336 updated to when that new information may be pushed or pulled into a 337 set of routers via this protocol. This may result in sudden shifts 338 of traffic in the operator's network, until all of the routers in the 339 AS have reached equilibrium with the validity state of prefixes 340 reflected in all of the RPKI caches. 342 It is hoped that testing and deployment will produce advice on 343 relying party cache loading and timing. 345 There is some uncertainty about the origin AS of aggregates and what, 346 if any, ROA can be used. The long range solution to this is the 347 deprecation of AS-SETs, see [RFC6472]. 349 As reliable access to the global RPKI and an operator's caches (and 350 possibly other hosts, e.g. DNS root servers) is important, an 351 operator SHOULD take advantage of relying party tools which report 352 changes in BGP or RPKI data which would negatively affect validation 353 of such prefixes. 355 Operators should be aware that there is a trade-off in placement of 356 an RPKI repository in address space for which the repository's 357 content is authoritative. On one hand, an operator will wish to 358 maximize control over the repository. On the other hand, if there 359 are reachability problems to the address space, changes in the 360 repository to correct them may not be easily accessed by others. 362 Operators who manage certificates SHOULD associate RPKI Ghostbusters 363 Records (see [RFC6493]) with each publication point they control. 364 These are publication points holding the CRL, ROAs, and other signed 365 objects issued by the operator, and made available to other ASs in 366 support of routing on the public Internet. 368 Routers which perform RPKI-based origin validation must support Four- 369 octet AS Numbers (see [RFC4893]), as, among other things, it is not 370 reasonable to generate ROAs for AS 23456. 372 Software which produces filter lists or other control forms for 373 routers where the target router does not support Four-octet AS 374 Numbers (see [RFC4893]) must be prepared to accept Four-octet AS 375 Numbers and generate the appropriate two-octet output. 377 As a router must evaluate certificates and ROAs which are time 378 dependent, routers' clocks MUST be correct to a tolerance of 379 approximately an hour. 381 Servers should provide time service, such as [RFC5905], to client 382 routers. 384 7. Security Considerations 386 As the BGP origin AS of an update is not signed, origin validation is 387 open to malicious spoofing. Therefore, RPKI-based origin validation 388 is expected to deal only with inadvertent mis-advertisement. 390 Origin validation does not address the problem of AS-Path validation. 391 Therefore paths are open to manipulation, either malicious or 392 accidental. 394 As BGP does not ensure that traffic will flow via the paths it 395 advertises, the data plane may not follow the control plane. 397 Be aware of the class of privilege escalation issues discussed in 398 Section 5 above. 400 8. IANA Considerations 402 This document has no IANA Considerations. 404 9. Acknowledgments 406 The author wishes to thank Shane Amante, Rob Austein, Steve Bellovin, 407 Jay Borkenhagen, Wes George, Seiichi Kawamura, Steve Kent, Pradosh 408 Mohapatra, Chris Morrow, Sandy Murphy, Eric Osterweil, Keyur Patel, 409 Heather and Jason Schiller, John Scudder, Kotikalapudi Sriram, 410 Maureen Stillman, and Dave Ward. 412 10. References 414 10.1. Normative References 416 [I-D.ietf-sidr-ltamgmt] 417 Reynolds, M., Kent, S., and M. Lepinski, "Local Trust 418 Anchor Management for the Resource Public Key 419 Infrastructure", draft-ietf-sidr-ltamgmt-07 (work in 420 progress), October 2012. 422 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 423 Requirement Levels", BCP 14, RFC 2119, March 1997. 425 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 426 Number Space", RFC 4893, May 2007. 428 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 429 Scheme", RFC 5781, February 2010. 431 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 432 Secure Internet Routing", RFC 6480, February 2012. 434 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 435 Resource Certificate Repository Structure", RFC 6481, 436 February 2012. 438 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 439 Origin Authorizations (ROAs)", RFC 6482, February 2012. 441 [RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 442 "Resource Public Key Infrastructure (RPKI) Trust Anchor 443 Locator", RFC 6490, February 2012. 445 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 446 Ghostbusters Record", RFC 6493, February 2012. 448 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 449 Infrastructure (RPKI) to Router Protocol", RFC 6810, 450 January 2013. 452 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 453 Austein, "BGP Prefix Origin Validation", RFC 6811, January 454 2013. 456 10.2. Informative References 458 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 459 Protocol 4 (BGP-4)", RFC 4271, January 2006. 461 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 462 Time Protocol Version 4: Protocol and Algorithms 463 Specification", RFC 5905, June 2010. 465 [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using 466 AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, 467 December 2011. 469 [rcynic] , "rcynic read-me", , 470 . 472 Author's Address 473 Randy Bush 474 Internet Initiative Japan 475 5147 Crystal Springs 476 Bainbridge Island, Washington 98110 477 US 479 Email: randy@psg.com