idnits 2.17.1 draft-ietf-sidr-origin-ops-15.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 3 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 (March 10, 2012) is 4420 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-04 == Outdated reference: A later version (-10) exists of draft-ietf-sidr-pfx-validate-03 ** 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 (~~), 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: BCP March 10, 2012 5 Expires: September 11, 2012 7 RPKI-Based Origin Validation Operation 8 draft-ietf-sidr-origin-ops-15 10 Abstract 12 Deployment of RPKI-based BGP origin validation has many operational 13 considerations. This document attempts to collect and present them. 14 It is expected to evolve as RPKI-based origin validation is deployed 15 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 September 11, 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 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3 59 3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . 3 60 4. Within a Network . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 10.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 RPKI-based origin validation relies on widespread deployment of the 74 Resource Public Key Infrastructure (RPKI) [RFC6480]. How the RPKI is 75 distributed and maintained globally is a serious concern from many 76 aspects. 78 The global RPKI is in very initial stages of deployment, there is no 79 single root trust anchor, initial testing is being done by the IANA 80 and the RIRs, and there are technical testbeds. It is thought that 81 origin validation based on the RPKI will be deployed incrementally 82 over the next year to five years. It is assumed that eventually 83 there will be a single root trust anchor for the public address 84 space. 86 Origin validation needs to be done only by an AS's border routers and 87 is designed so that it can be used to protect announcements which are 88 originated by any network participating in Internet BGP routing: 89 large providers, upstreams and down-streams, and by small stub/ 90 enterprise/edge routers. 92 Origin validation has been designed to be deployed on current routers 93 without significant hardware upgrade. It should be used in border 94 routers by operators from large backbones to small stub/entetprise/ 95 edge networks. 97 RPKI-based origin validation has been designed so that, with prudent 98 local routing policies, there is little risk that what is seen as 99 today's normal Internet routing is threatened by imprudent deployment 100 of the global RPKI, see Section 5. 102 2. Suggested Reading 104 It is assumed that the reader understands BGP, [RFC4271], the RPKI, 105 see [RFC6480], the RPKI Repository Structure, see [RFC6481], ROAs, 106 see [RFC6482], the RPKI to Router Protocol, see 107 [I-D.ietf-sidr-rpki-rtr], RPKI-based Prefix Validation, see 108 [I-D.ietf-sidr-pfx-validate], and Ghostbusters Records, see 109 [RFC6493]. 111 3. RPKI Distribution and Maintenance 113 The RPKI is a distributed database containing certificates, CRLs, 114 manifests, ROAs, and Ghostbusters Records as described in [RFC6481]. 115 Policies and considerations for RPKI object generation and 116 maintenance are discussed elsewhere. 118 A local relying party valid cache containing all RPKI data may be 119 gathered from the global distributed database using the rsync 120 protocol, [RFC5781], and a validation tool such as rcynic [rcynic]. 122 Validated caches may also be created and maintained from other 123 validated caches. Network operators SHOULD take maximum advantage of 124 this feature to minimize load on the global distributed RPKI 125 database. Of course, the recipient relying parties SHOULD re- 126 validate the data. 128 Timing of inter-cache synchronization, and synchronization between 129 caches and the global RPKI, is outside the scope of this document, 130 and depends on things such as how often routers feed from the caches, 131 how often the operator feels the global RPKI changes significantly, 132 etc. 134 As inter-cache synchronization within an operator's network does not 135 impact global RPKI resources, an operator MAY choose to synchronize 136 quite frequently. 138 As RPKI-based origin validation relies on the availability of RPKI 139 data, operators SHOULD locate caches close to routers that require 140 these data and services. 'Close' is, of course, complex. One should 141 consider trust boundaries, routing bootstrap reachability, latency, 142 etc. 144 If insecure transports are used between an operator's cache and their 145 router(s), the Transport Security recommendations in 146 [I-D.ietf-sidr-rpki-rtr] SHOULD be followed. In particular, 147 operators MUST NOT use insecure transports between their routers and 148 RPKI caches located in other Autonomous Systems. 150 For redundancy, a router SHOULD peer with more than one cache at the 151 same time. Peering with two or more, at least one local and others 152 remote, is recommended. 154 If an operator trusts upstreams to carry their traffic, they MAY also 155 trust the RPKI data those upstreams cache, and SHOULD peer with 156 caches made available to them by those upstreams. Note that this 157 places an obligation on those upstreams to maintain fresh and 158 reliable caches, and to make them available to their customers. And, 159 as usual, the recipient SHOULD re-validate the data. 161 A transit provider or a network with peers SHOULD validate origins in 162 announcements made by upstreams, down-streams, and peers. They still 163 SHOULD trust the caches provided by their upstreams. 165 Before issuing a ROA for a super-block, an operator MUST ensure that 166 all sub-allocations from that block which are announced by other ASs, 167 e.g. customers, have correct ROAs in the RPKI. Otherwise, issuing a 168 ROA for the super-block will cause the announcements of sub- 169 allocations with no ROAs to be viewed as Invalid, see 170 [I-D.ietf-sidr-pfx-validate]. 172 Use of RPKI-based origin validation removes any need to originate 173 more specifics into BGP to protect against mis-origination of a less 174 specific prefix. Having a ROA for the covering prefix will protect 175 it. 177 To aid translation of ROAs into efficient search algorithms in 178 routers, ROAs SHOULD be as precise as possible, i.e. match prefixes 179 as announced in BGP. E.g. software and operators SHOULD avoid use of 180 excessive max length values in ROAs unless operationally necessary. 182 One advantage of minimal ROA length is that the forged origin attack 183 does not work for sub-prefixes that are not covered by overly long 184 max length. E.g. if, instead of 10.0.0.0/16-24, one issues 185 10.0.0.0/16 and 10.0.42.0/24, a forged origin attack can not succeed 186 against 10.0.66.0/24. They must attack the whole /16, which is more 187 likely to be noticed because of its size. 189 Therefore, ROA generation software MUST use the prefix length as the 190 max length if the user does not specify a max length. 192 Operators SHOULD be conservative in use of max length in ROAs. E.g., 193 if a prefix will have only a few sub-prefixes announced, multiple 194 ROAs for the specific announcements SHOULD be used as opposed to one 195 ROA with a long max length. 197 Operators owning prefix P should issue ROAs for all ASs which may 198 announce P. If a prefix is legitimately announced by more than one 199 AS, ROAs for all of the ASs SHOULD be issued so that all are 200 considered Valid. 202 An environment where private address space is announced in eBGP the 203 operator MAY have private RPKI objects which cover these private 204 spaces. This will require a trust anchor created and owned by that 205 environment, see [I-D.ietf-sidr-ltamgmt]. 207 Operators issuing ROAs may have customers which announce their own 208 prefixes and ASs into global eBGP but who do not wish to go though 209 the work to manage the relevant certificates and ROAs. Operators 210 SHOULD offer to provision the RPKI data for these customers just as 211 they provision many other things for them. 213 While an operator using RPKI data MAY choose any polling frequency 214 they wish for ensuring they have a fresh RPKI cache. However, if 215 they use RPKI data as an input to operational routing decisions, they 216 SHOULD ensure local caches inside their AS are synchronized with each 217 other at least every four to six hours. 219 Operators should use tools which warn them of any impending ROA or 220 certificate expiry which could affect the validity of their own data. 221 Ghostbuster Records, see [RFC6493], can be used to facilitate contact 222 with upstream CAs to effect repair. 224 4. Within a Network 226 Origin validation need only be done by edge routers in a network, 227 those which border other networks/ASs. 229 A validating router will use the result of origin validation to 230 influence local policy within its network, see Section 5. In 231 deployment this policy should fit into the AS's existing policy, 232 preferences, etc. This allows a network to incrementally deploy 233 validation-capable border routers. 235 5. Routing Policy 237 Origin validation based on the RPKI marks a received announcement as 238 having an origin which is Valid, NotFound, or Invalid, see 239 [I-D.ietf-sidr-pfx-validate]. How this is used in routing SHOULD be 240 specified by the operator's local policy. 242 Local policy using relative preference is suggested to manage the 243 uncertainty associated with a system in early deployment, applying 244 local policy to eliminate the threat of unreachability of prefixes 245 due to ill-advised certification policies and/or incorrect 246 certification data. E.g. until the community feels comfortable 247 relying on RPKI data, routing on Invalid origin validity, though at a 248 low preference, MAY occur. 250 As origin validation will be rolled out incrementally, coverage will 251 be incomplete for a long time. Therefore, routing on NotFound 252 validity state SHOULD be done for a long time. As the transition 253 moves forward, the number of BGP announcements with validation state 254 NotFound should decrease. Hence an operator's policy SHOULD NOT be 255 overly strict, and should prefer Valid announcements, attaching a 256 lower preference to, but still using, NotFound announcements, and 257 dropping or giving a very low preference to Invalid announcements. 259 Some providers may choose to set Local-Preference based on the RPKI 260 validation result. Other providers may not want the RPKI validation 261 result to be more important than AS-path length -- these providers 262 would need to map RPKI validation result to some BGP attribute that 263 is evaluated in BGP's path selection process after AS-path is 264 evaluated. Routers implementing RPKI-based origin validation MUST 265 provide such options to operators. 267 Local-Preference may be used to carry both the validity state of a 268 prefix along with it's traffic engineering characteristic(s). It is 269 likely that an operator already using Local-Preference will have to 270 change policy so they can encode these two separate characteristics 271 in the same BGP attribute without negatively impact or opening 272 privilege escalation attacks. 274 When using a metric which is also influenced by other local policy, 275 an operator should be careful not to create privilege upgrade 276 vulnerabilities. E.g. if Local Pref is set depending on validity 277 state, be careful that peer community signaling MAY NOT upgrade an 278 Invalid announcement to Valid or better. 280 Announcements with Valid origins SHOULD be preferred over those with 281 NotFound or Invalid origins, if the latter are accepted at all. 283 Announcements with NotFound origins SHOULD be preferred over those 284 with Invalid origins. 286 Announcements with Invalid origins SHOULD NOT be used, but MAY be 287 used to meet special operational needs. In such circumstances, the 288 announcement SHOULD have a lower preference than that given to Valid 289 or NotFound. 291 Validity state signaling SHOULD NOT be accepted from a neighbor AS. 292 The validity state of a received announcement has only local scope 293 due to issues such as scope of trust, RPKI synchrony, and 294 [I-D.ietf-sidr-ltamgmt]. 296 6. Notes 298 Like the DNS, the global RPKI presents only a loosely consistent 299 view, depending on timing, updating, fetching, etc. Thus, one cache 300 or router may have different data about a particular prefix than 301 another cache or router. There is no 'fix' for this, it is the 302 nature of distributed data with distributed caches. 304 Operators should beware that RPKI caches are loosely synchronized, 305 even within a single AS. Thus, changes to the validity state of 306 prefixes could be different within an operator's network. In 307 addition, there is no guaranteed interval from when an RPKI cache is 308 updated to when that new information may be pushed or pulled into a 309 set of routers via this protocol. This may result in sudden shifts 310 of traffic in the operator's network, until all of the routers in the 311 AS have reached equilibrium with the validity state of prefixes 312 reflected in all of the RPKI caches. 314 It is hoped that testing and deployment will produce advice on 315 relying party cache loading and timing. 317 There is some uncertainty about the origin AS of aggregates and what, 318 if any, ROA can be used. The long range solution to this is the 319 deprecation of AS-SETs, see [I-D.wkumari-deprecate-as-sets]. 321 As reliable access to the global RPKI and an operator's caches (and 322 possibly other hosts, e.g. DNS root servers) is important, an 323 operator SHOULD take advantage of relying party tools which report 324 changes in BGP or RPKI data which would negatively affect validation 325 of such prefixes. 327 Operators who manage certificates SHOULD associate RPKI Ghostbusters 328 Records (see [RFC6493]) with each publication point they control. 329 These are publication points holding the CRL, ROAs, and other signed 330 objects issued by the operator, and made available to other ASs in 331 support of routing on the public Internet. 333 As a router must evaluate certificates and ROAs which are time 334 dependent, routers' clocks MUST be correct to a tolerance of 335 approximately an hour. 337 It is not reasonable to expect RPKI-based validation to run on 338 routers which do not support Four-octet AS Numbers (see [RFC4893], as 339 it is not reasonable to generate ROAs for AS 23456. 341 Servers should provide time service, such as [RFC5905], to client 342 routers. 344 7. Security Considerations 346 As the BGP origin AS of an update is not signed, origin validation is 347 open to malicious spoofing. Therefore, RPKI-based origin validation 348 is expected to deal only with inadvertent mis-advertisement. 350 Origin validation does not address the problem of AS-Path validation. 351 Therefore paths are open to manipulation, either malicious or 352 accidental. 354 As BGP does not ensure that traffic will flow via the paths it 355 advertises, the data plane may not follow the control plane. 357 Be aware of the class of privilege escalation issues discussed in 358 Section 5 above. 360 8. IANA Considerations 362 This document has no IANA Considerations. 364 9. Acknowledgments 366 The author wishes to thank Shane Amante, Rob Austein, Steve Bellovin, 367 Jay Borkenhagen, Steve Kent, Pradosh Mohapatra, Chris Morrow, Sandy 368 Murphy, Keyur Patel, Heather and Jason Schiller, John Scudder, 369 Kotikalapudi Sriram, Maureen Stillman, and Dave Ward. 371 10. References 373 10.1. Normative References 375 [I-D.ietf-sidr-ltamgmt] 376 Reynolds, M. and S. Kent, "Local Trust Anchor Management 377 for the Resource Public Key Infrastructure", 378 draft-ietf-sidr-ltamgmt-04 (work in progress), 379 December 2011. 381 [I-D.ietf-sidr-pfx-validate] 382 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 383 Austein, "BGP Prefix Origin Validation", 384 draft-ietf-sidr-pfx-validate-03 (work in progress), 385 October 2011. 387 [I-D.ietf-sidr-rpki-rtr] 388 Bush, R. and R. Austein, "The RPKI/Router Protocol", 389 draft-ietf-sidr-rpki-rtr-26 (work in progress), 390 February 2012. 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 396 Number Space", RFC 4893, May 2007. 398 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 399 Scheme", RFC 5781, February 2010. 401 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 402 Secure Internet Routing", RFC 6480, February 2012. 404 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 405 Resource Certificate Repository Structure", RFC 6481, 406 February 2012. 408 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 409 Origin Authorizations (ROAs)", RFC 6482, February 2012. 411 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 412 Ghostbusters Record", RFC 6493, February 2012. 414 10.2. Informative References 416 [I-D.wkumari-deprecate-as-sets] 417 Kumari, W., "Deprecation of BGP AS_SET, AS_CONFED_SET.", 418 draft-wkumari-deprecate-as-sets-01 (work in progress), 419 September 2010. 421 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 422 Protocol 4 (BGP-4)", RFC 4271, January 2006. 424 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 425 Time Protocol Version 4: Protocol and Algorithms 426 Specification", RFC 5905, June 2010. 428 [rcynic] "rcynic read-me", 429 . 431 Author's Address 433 Randy Bush 434 Internet Initiative Japan 435 5147 Crystal Springs 436 Bainbridge Island, Washington 98110 437 US 439 Phone: +1 206 780 0431 x1 440 Email: randy@psg.com