idnits 2.17.1 draft-ietf-sidr-origin-ops-17.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 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 (June 2012) is 4323 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) == Unused Reference: 'I-D.ietf-sidr-rpki-rtr' is defined on line 409, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-sidr-ltamgmt-05 == Outdated reference: A later version (-10) exists of draft-ietf-sidr-pfx-validate-06 ** 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 Summary: 3 errors (**), 0 flaws (~~), 6 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 June 2012 5 Expires: December 01, 2012 7 RPKI-Based Origin Validation Operation 8 draft-ietf-sidr-origin-ops-17 10 Abstract 12 Deployment of RPKI-based BGP origin validation has many operational 13 considerations. This document attempts to collect and present the 14 most critical. It is expected to evolve as RPKI-based origin 15 validation is deployed and the dynamics are better understood. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 01, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2 58 3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . 3 59 4. Within a Network . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 10.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 RPKI-based origin validation relies on widespread deployment of the 73 Resource Public Key Infrastructure (RPKI) [RFC6480]. How the RPKI is 74 distributed and maintained globally is a serious concern from many 75 aspects. 77 The global RPKI is in very initial stages of deployment, there is no 78 single root trust anchor, initial testing is being done by the IANA 79 and the RIRs, and there are technical testbeds. It is thought that 80 origin validation based on the RPKI will be deployed incrementally 81 over the next year to five years. It is assumed that eventually 82 there will be a single root trust anchor for the public address 83 space. 85 Origin validation needs to be done only by an AS's border routers and 86 is designed so that it can be used to protect announcements which are 87 originated by any network participating in Internet BGP routing: 88 large providers, upstreams and down-streams, and by small stub/ 89 enterprise/edge routers. 91 Origin validation has been designed to be deployed on current routers 92 without significant hardware upgrade. It should be used in border 93 routers by operators from large backbones to small stub/entetprise/ 94 edge networks. 96 RPKI-based origin validation has been designed so that, with prudent 97 local routing policies, there is little risk that what is seen as 98 today's normal Internet routing is threatened by imprudent deployment 99 of the global RPKI, see Section 5. 101 2. Suggested Reading 102 It is assumed that the reader understands BGP, [RFC4271], the RPKI, 103 see [RFC6480], the RPKI Repository Structure, see [RFC6481], ROAs, 104 see [RFC6482], the RPKI to Router Protocol, see [I-D.ietf-sidr-rpki- 105 rtr], RPKI-based Prefix Validation, see [I-D.ietf-sidr-pfx-validate], 106 and Ghostbusters Records, see [RFC6493]. 108 3. RPKI Distribution and Maintenance 110 The RPKI is a distributed database containing certificates, CRLs, 111 manifests, ROAs, and Ghostbusters Records as described in [RFC6481]. 112 Policies and considerations for RPKI object generation and 113 maintenance are discussed elsewhere. 115 A local relying party valid cache containing all RPKI data may be 116 gathered from the global distributed database using the rsync 117 protocol, [RFC5781], and a validation tool such as rcynic [rcynic]. 119 Validated caches may also be created and maintained from other 120 validated caches. Network operators SHOULD take maximum advantage of 121 this feature to minimize load on the global distributed RPKI 122 database. Of course, the recipient relying parties SHOULD re- 123 validate the data. 125 Timing of inter-cache synchronization, and synchronization between 126 caches and the global RPKI, is outside the scope of this document, 127 and depends on things such as how often routers feed from the caches, 128 how often the operator feels the global RPKI changes significantly, 129 etc. 131 As inter-cache synchronization within an operator's network does not 132 impact global RPKI resources, an operator MAY choose to synchronize 133 quite frequently. 135 As RPKI-based origin validation relies on the availability of RPKI 136 data, operators SHOULD locate caches close to routers that require 137 these data and services. 'Close' is, of course, complex. One should 138 consider trust boundaries, routing bootstrap reachability, latency, 139 etc. 141 If insecure transports are used between an operator's cache and their 142 router(s), the Transport Security recommendations in [I-D.ietf-sidr- 143 rpki-rtr] SHOULD be followed. In particular, operators MUST NOT use 144 insecure transports between their routers and RPKI caches located in 145 other Autonomous Systems. 147 For redundancy, a router SHOULD peer with more than one cache at the 148 same time. Peering with two or more, at least one local and others 149 remote, is recommended. 151 If an operator trusts upstreams to carry their traffic, they MAY also 152 trust the RPKI data those upstreams cache, and SHOULD peer with 153 caches made available to them by those upstreams. Note that this 154 places an obligation on those upstreams to maintain fresh and 155 reliable caches, and to make them available to their customers. And, 156 as usual, the recipient SHOULD re-validate the data. 158 A transit provider or a network with peers SHOULD validate origins in 159 announcements made by upstreams, down-streams, and peers. They still 160 SHOULD trust the caches provided by their upstreams. 162 Before issuing a ROA for a super-block, an operator MUST ensure that 163 all sub-allocations from that block which are announced by other ASs, 164 e.g. customers, have correct ROAs in the RPKI. Otherwise, issuing a 165 ROA for the super-block will cause the announcements of sub- 166 allocations with no ROAs to be viewed as Invalid, see [I-D.ietf-sidr- 167 pfx-validate]. 169 Use of RPKI-based origin validation removes any need to originate 170 more specifics into BGP to protect against mis-origination of a less 171 specific prefix. Having a ROA for the covering prefix will protect 172 it. 174 To aid translation of ROAs into efficient search algorithms in 175 routers, ROAs SHOULD be as precise as possible, i.e. match prefixes 176 as announced in BGP. E.g. software and operators SHOULD avoid use 177 of excessive max length values in ROAs unless operationally 178 necessary. 180 One advantage of minimal ROA length is that the forged origin attack 181 does not work for sub-prefixes that are not covered by overly long 182 max length. E.g. if, instead of 10.0.0.0/16-24, one issues 10.0.0.0 183 /16 and 10.0.42.0/24, a forged origin attack can not succeed against 184 10.0.66.0/24. They must attack the whole /16, which is more likely 185 to be noticed because of its size. 187 Therefore, ROA generation software MUST use the prefix length as the 188 max length if the user does not specify a max length. 190 Operators SHOULD be conservative in use of max length in ROAs. E.g., 191 if a prefix will have only a few sub-prefixes announced, multiple 192 ROAs for the specific announcements SHOULD be used as opposed to one 193 ROA with a long max length. 195 Operators owning prefix P should issue ROAs for all ASs which may 196 announce P. If a prefix is legitimately announced by more than one 197 AS, ROAs for all of the ASs SHOULD be issued so that all are 198 considered Valid. 200 An environment where private address space is announced in eBGP the 201 operator MAY have private RPKI objects which cover these private 202 spaces. This will require a trust anchor created and owned by that 203 environment, see [I-D.ietf-sidr-ltamgmt]. 205 Operators issuing ROAs may have customers which announce their own 206 prefixes and ASs into global eBGP but who do not wish to go though 207 the work to manage the relevant certificates and ROAs. Operators 208 SHOULD offer to provision the RPKI data for these customers just as 209 they provision many other things for them. 211 While an operator using RPKI data MAY choose any polling frequency 212 they wish for ensuring they have a fresh RPKI cache. However, if 213 they use RPKI data as an input to operational routing decisions, they 214 SHOULD ensure local caches inside their AS are synchronized with each 215 other at least every four to six hours. 217 Operators should use tools which warn them of any impending ROA or 218 certificate expiry which could affect the validity of their own data. 219 Ghostbuster Records, see [RFC6493], can be used to facilitate contact 220 with upstream CAs to effect repair. 222 4. Within a Network 224 Origin validation need only be done by edge routers in a network, 225 those which border other networks/ASs. 227 A validating router will use the result of origin validation to 228 influence local policy within its network, see Section 5. In 229 deployment this policy should fit into the AS's existing policy, 230 preferences, etc. This allows a network to incrementally deploy 231 validation-capable border routers. 233 The operator should be aware that RPKI-based origin validation, as 234 any other policy change, can cause traffic shifts in their network. 235 And, as with normal policy shift practice, a prudent operator has 236 tools and methods to predict, measure, modify, etc. 238 5. Routing Policy 240 Origin validation based on the RPKI marks a received announcement as 241 having an origin which is Valid, NotFound, or Invalid, see [I-D.ietf- 242 sidr-pfx-validate]. How this is used in routing SHOULD be specified 243 by the operator's local policy. 245 Local policy using relative preference is suggested to manage the 246 uncertainty associated with a system in early deployment, applying 247 local policy to eliminate the threat of unreachability of prefixes 248 due to ill-advised certification policies and/or incorrect 249 certification data. E.g. until the community feels comfortable 250 relying on RPKI data, routing on Invalid origin validity, though at a 251 low preference, MAY occur. 253 Operators should be aware that accepting Invalid announcements, no 254 matter how de-preffed, will often be the equivalent of treating them 255 as fully Valid. Consider having a ROA for AS 42 for prefix 10.0.0.0/ 256 16-24. A BGP announcement for 10.0.666.0/24 from AS 666 would be 257 Invalid. But if policy is not configured to discard it, then longest 258 match forwarding will send packets to AS 666 no matter the value of 259 local preference. 261 As origin validation will be rolled out incrementally, coverage will 262 be incomplete for a long time. Therefore, routing on NotFound 263 validity state SHOULD be done for a long time. As the transition 264 moves forward, the number of BGP announcements with validation state 265 NotFound should decrease. Hence an operator's policy SHOULD NOT be 266 overly strict, and should prefer Valid announcements, attaching a 267 lower preference to, but still using, NotFound announcements, and 268 dropping or giving a very low preference to Invalid announcements. 270 Some providers may choose to set Local-Preference based on the RPKI 271 validation result. Other providers may not want the RPKI validation 272 result to be more important than AS-path length -- these providers 273 would need to map RPKI validation result to some BGP attribute that 274 is evaluated in BGP's path selection process after AS-path is 275 evaluated. Routers implementing RPKI-based origin validation MUST 276 provide such options to operators. 278 Local-Preference may be used to carry both the validity state of a 279 prefix along with it's traffic engineering characteristic(s). It is 280 likely that an operator already using Local-Preference will have to 281 change policy so they can encode these two separate characteristics 282 in the same BGP attribute without negatively impact or opening 283 privilege escalation attacks. 285 When using a metric which is also influenced by other local policy, 286 an operator should be careful not to create privilege upgrade 287 vulnerabilities. E.g. if Local Pref is set depending on validity 288 state, be careful that peer community signaling MAY NOT upgrade an 289 Invalid announcement to Valid or better. 291 Announcements with Valid origins SHOULD be preferred over those with 292 NotFound or Invalid origins, if the latter are accepted at all. 294 Announcements with NotFound origins SHOULD be preferred over those 295 with Invalid origins. 297 Announcements with Invalid origins SHOULD NOT be used, but MAY be 298 used to meet special operational needs. In such circumstances, the 299 announcement SHOULD have a lower preference than that given to Valid 300 or NotFound. 302 Validity state signaling SHOULD NOT be accepted from a neighbor AS. 303 The validity state of a received announcement has only local scope 304 due to issues such as scope of trust, RPKI synchrony, and [I-D.ietf- 305 sidr-ltamgmt]. 307 6. Notes 309 Like the DNS, the global RPKI presents only a loosely consistent 310 view, depending on timing, updating, fetching, etc. Thus, one cache 311 or router may have different data about a particular prefix than 312 another cache or router. There is no 'fix' for this, it is the 313 nature of distributed data with distributed caches. 315 Operators should beware that RPKI caches are loosely synchronized, 316 even within a single AS. Thus, changes to the validity state of 317 prefixes could be different within an operator's network. In 318 addition, there is no guaranteed interval from when an RPKI cache is 319 updated to when that new information may be pushed or pulled into a 320 set of routers via this protocol. This may result in sudden shifts 321 of traffic in the operator's network, until all of the routers in the 322 AS have reached equilibrium with the validity state of prefixes 323 reflected in all of the RPKI caches. 325 It is hoped that testing and deployment will produce advice on 326 relying party cache loading and timing. 328 There is some uncertainty about the origin AS of aggregates and what, 329 if any, ROA can be used. The long range solution to this is the 330 deprecation of AS-SETs, see [I-D.wkumari-deprecate-as-sets]. 332 As reliable access to the global RPKI and an operator's caches (and 333 possibly other hosts, e.g. DNS root servers) is important, an 334 operator SHOULD take advantage of relying party tools which report 335 changes in BGP or RPKI data which would negatively affect validation 336 of such prefixes. 338 Operators should be aware that there is a trade-off in placement of 339 an RPKI repository in address space for which the repository's 340 content is authoritative. On one hand, an operator will wish to 341 maximize control over the repository. On the other hand, if there 342 are reachability problems to the address space, changes in the 343 repository to correct them may not be easily accessed by others. 345 Operators who manage certificates SHOULD associate RPKI Ghostbusters 346 Records (see [RFC6493]) with each publication point they control. 347 These are publication points holding the CRL, ROAs, and other signed 348 objects issued by the operator, and made available to other ASs in 349 support of routing on the public Internet. 351 Routers which perform RPKI-based origin validation must support Four- 352 octet AS Numbers (see [RFC4893]), as, among other things, it is not 353 reasonable to generate ROAs for AS 23456. 355 Software which produces filter lists or other control forms for 356 routers where the target router does not support Four-octet AS 357 Numbers (see [RFC4893]) must be prepared to accept Four-octet AS 358 Numbers and generate the appropriate two-octet output. 360 As a router must evaluate certificates and ROAs which are time 361 dependent, routers' clocks MUST be correct to a tolerance of 362 approximately an hour. 364 Servers should provide time service, such as [RFC5905], to client 365 routers. 367 7. Security Considerations 369 As the BGP origin AS of an update is not signed, origin validation is 370 open to malicious spoofing. Therefore, RPKI-based origin validation 371 is expected to deal only with inadvertent mis-advertisement. 373 Origin validation does not address the problem of AS-Path validation. 374 Therefore paths are open to manipulation, either malicious or 375 accidental. 377 As BGP does not ensure that traffic will flow via the paths it 378 advertises, the data plane may not follow the control plane. 380 Be aware of the class of privilege escalation issues discussed in 381 Section 5 above. 383 8. IANA Considerations 385 This document has no IANA Considerations. 387 9. Acknowledgments 389 The author wishes to thank Shane Amante, Rob Austein, Steve Bellovin, 390 Jay Borkenhagen, Wes George, Steve Kent, Pradosh Mohapatra, Chris 391 Morrow, Sandy Murphy, Keyur Patel, Heather and Jason Schiller, John 392 Scudder, Kotikalapudi Sriram, Maureen Stillman, and Dave Ward. 394 10. References 396 10.1. Normative References 398 [I-D.ietf-sidr-ltamgmt] 399 Reynolds, M., Kent, S. and M. Lepinski, "Local Trust 400 Anchor Management for the Resource Public Key 401 Infrastructure", Internet-Draft draft-ietf-sidr- 402 ltamgmt-05, June 2012. 404 [I-D.ietf-sidr-pfx-validate] 405 Mohapatra, P., Scudder, J., Ward, D., Bush, R. and R. 406 Austein, "BGP Prefix Origin Validation", Internet-Draft 407 draft-ietf-sidr-pfx-validate-06, May 2012. 409 [I-D.ietf-sidr-rpki-rtr] 410 Bush, R. and R. Austein, "The RPKI/Router Protocol", 411 Internet-Draft draft-ietf-sidr-rpki-rtr-26, February 2012. 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, March 1997. 416 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 417 Number Space", RFC 4893, May 2007. 419 [RFC5781] Weiler, S., Ward, D. and R. Housley, "The rsync URI 420 Scheme", RFC 5781, February 2010. 422 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 423 Secure Internet Routing", RFC 6480, February 2012. 425 [RFC6481] Huston, G., Loomans, R. and G. Michaelson, "A Profile for 426 Resource Certificate Repository Structure", RFC 6481, 427 February 2012. 429 [RFC6482] Lepinski, M., Kent, S. and D. Kong, "A Profile for Route 430 Origin Authorizations (ROAs)", RFC 6482, February 2012. 432 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 433 Ghostbusters Record", RFC 6493, February 2012. 435 10.2. Informative References 437 [I-D.wkumari-deprecate-as-sets] 438 Kumari, W., "Deprecation of BGP AS_SET, AS_CONFED_SET.", 439 Internet-Draft draft-wkumari-deprecate-as-sets-01, 440 September 2010. 442 [RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway 443 Protocol 4 (BGP-4)", RFC 4271, January 2006. 445 [RFC5905] Mills, D., Martin, J., Burbank, J. and W. Kasch, "Network 446 Time Protocol Version 4: Protocol and Algorithms 447 Specification", RFC 5905, June 2010. 449 [rcynic] "rcynic read-me", , . 452 Author's Address 453 Randy Bush 454 Internet Initiative Japan 455 5147 Crystal Springs 456 Bainbridge Island, Washington 98110 457 US 459 Phone: +1 206 780 0431 x1 460 Email: randy@psg.com