idnits 2.17.1 draft-ietf-sidr-origin-ops-13.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 (November 14, 2011) is 4546 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) ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'I-D.ietf-sidr-arch') == Outdated reference: A later version (-16) exists of draft-ietf-sidr-ghostbusters-15 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-ltamgmt-02 == Outdated reference: A later version (-10) exists of draft-ietf-sidr-pfx-validate-03 == Outdated reference: A later version (-26) exists of draft-ietf-sidr-rpki-rtr-19 ** Downref: Normative reference to an Informational RFC: RFC 5781 Summary: 2 errors (**), 0 flaws (~~), 7 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 November 14, 2011 5 Expires: May 17, 2012 7 RPKI-Based Origin Validation Operation 8 draft-ietf-sidr-origin-ops-13 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 May 17, 2012. 40 Copyright Notice 42 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 RPKI-based origin validation relies on widespread deployment of the 74 Resource Public Key Infrastructure (RPKI) [I-D.ietf-sidr-arch]. How 75 the RPKI is distributed and maintained globally is a serious concern 76 from many 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 is a technical testbed. It is thought that 81 origin validation based on the RPKI will be deployed incrementally 82 over the next year to five years. 84 Origin validation needs to be done only by an AS's border routers and 85 is designed so that it can be used to protect announcements which are 86 originated by any network participating in Internet BGP routing: 87 large providers, upstreams and down-streams, and by small stub/ 88 enterprise/edge routers. 90 Origin validation has been designed to be deployed on current routers 91 without significant hardware upgrade. It should be used in border 92 routers by operators from large backbones to small stub/entetprise/ 93 edge networks. 95 RPKI-based origin validation has been designed so that, with prudent 96 local routing policies, there is little risk that what is seen as 97 today's normal Internet routing is threatened by imprudent deployment 98 of the global RPKI, see Section 5. 100 2. Suggested Reading 102 It is assumed that the reader understands BGP, [RFC4271], the RPKI, 103 see [I-D.ietf-sidr-arch], the RPKI Repository Structure, see 104 [I-D.ietf-sidr-repos-struct], ROAs, see [I-D.ietf-sidr-roa-format], 105 the RPKI to Router Protocol, see [I-D.ietf-sidr-rpki-rtr], RPKI-based 106 Prefix Validation, see [I-D.ietf-sidr-pfx-validate], and Ghostbusters 107 Records, see [I-D.ietf-sidr-ghostbusters]. 109 3. RPKI Distribution and Maintenance 111 The RPKI is a distributed database containing certificates, CRLs, 112 manifests, ROAs, and Ghostbusters Records as described in 113 [I-D.ietf-sidr-repos-struct]. Policies and considerations for RPKI 114 object generation and maintenance are discussed elsewhere. 116 A local valid cache containing all RPKI data may be gathered from the 117 global distributed database using the rsync protocol, [RFC5781], and 118 a validation tool such as rcynic [rcynic]. 120 Validated caches may also be created and maintained from other 121 validated caches. Network operators SHOULD take maximum advantage of 122 this feature to minimize load on the global distributed RPKI 123 database. Of course, the recipient SHOULD re-validate the data. 125 Timing of inter-cache synchronization is outside the scope of this 126 document, but depends on things such as how often routers feed from 127 the caches, how often the operator feels the global RPKI changes 128 significantly, etc. 130 As inter-cache synchronization within an operator does not impact 131 global RPKI resources, an operator MAY choose to synchronize quite 132 frequently. 134 As RPKI-based origin validation relies on the availability of RPKI 135 data, operators SHOULD locate caches close to routers that require 136 these data and services. 'Close' is, of course, complex. One should 137 consider trust boundaries, routing bootstrap reachability, latency, 138 etc. 140 For redundancy, a router SHOULD peer with more than one cache at the 141 same time. Peering with two or more, at least one local and others 142 remote, is recommended. 144 If an operator trusts upstreams to carry their traffic, they MAY also 145 trust the RPKI data those upstreams cache, and SHOULD peer with 146 caches made available to them by those upstreams. Note that this 147 places an obligation on those upstreams to maintain fresh and 148 reliable caches, and to make them available to their customers. And, 149 as usual, the recipient SHOULD re-validate the data. 151 A transit provider or a network with peers SHOULD validate origins in 152 announcements made by upstreams, down-streams, and peers. They still 153 SHOULD trust the caches provided by their upstreams. 155 Before issuing a ROA for a super-block, an operator MUST ensure that 156 any sub-allocations from that block which are announced by other ASs, 157 e.g. customers, have correct ROAs in the RPKI. Otherwise, issuing a 158 ROA for the super-block will cause the announcements of sub- 159 allocations with no ROAs to be viewed as Invalid, see 160 [I-D.ietf-sidr-pfx-validate]. 162 Use of RPKI-based origin validation removes any need to originate 163 more specifics into BGP to protect against mis-origination of a less 164 specific prefix. Having a ROA for the covering prefix should protect 165 it. 167 To aid translation of ROAs into efficient search algorithms in 168 routers, ROAs SHOULD be as precise as possible, i.e. match prefixes 169 as announced in BGP. E.g. software and operators SHOULD avoid use of 170 excessive max length values in ROAs unless operationally necessary. 172 One advantage of minimal ROA length is that the forged origin attack 173 does not work for sub-prefixes that are not covered by overly long 174 max length. E.g. if, instead of 10.0.0.0/16-24, one issues 175 10.0.0.0/16 and 10.0.42.0/24, a forged origin attack can not succeed 176 against 10.0.66.0/24. They must attack the whole /16, which is more 177 likely to be noticed because of its size. 179 Therefore, ROA generation software MUST use the prefix length as the 180 max length if the user does not specify a max length. 182 Operators SHOULD be conservative in use of max length in ROAs. E.g., 183 if a prefix will have only a few sub-prefixes announced, multiple 184 ROAs for the specific announcements SHOULD be used as opposed to one 185 ROA with a long max length. 187 If a prefix is legitimately announced by more than one AS, ROAs for 188 all of the ASs SHOULD be issued so that all are considered Valid. 190 An environment where private address space is announced in eBGP the 191 operator MAY have private RPKI objects which cover these private 192 spaces. This will require a trust anchor created and owned by that 193 environment, see [I-D.ietf-sidr-ltamgmt]. 195 Operators owning prefix P should issue ROAs for all ASs which may 196 announce P. 198 Operators issuing ROAs may have customers which announce their own 199 prefixes and ASs into global eBGP but who do not wish to go though 200 the work to manage the relevant certificates and ROAs. Operators 201 SHOULD offer to provision the RPKI data for these customers just as 202 they provision many other things for them. 204 While an operator using RPKI data MAY choose any polling frequency 205 they wish for ensuring they have a fresh RPKI cache. However, if 206 they use RPKI data as an input to operational routing decisions, they 207 SHOULD ensure local cache freshness at least every four to six hours. 209 4. Within a Network 211 Origin validation need only be done by edge routers in a network, 212 those which border other networks/ASs. 214 A validating router will use the result of origin validation to 215 influence local policy within its network, see Section 5. In 216 deployment this policy should fit into the AS's existing policy, 217 preferences, etc. This allows a network to incrementally deploy 218 validation-capable border routers. 220 eBGP speakers which face more critical peers or up/down-streams are 221 candidates for the earliest deployment. Validating more critical 222 received announcements should be considered in partial deployment. 224 5. Routing Policy 226 Origin validation based on the RPKI marks a received announcement as 227 having an origin which is Valid, NotFound, or Invalid. See 228 [I-D.ietf-sidr-pfx-validate]. How this is used in routing SHOULD be 229 specified by the operator's local policy. 231 Local policy using relative preference is suggested to manage the 232 uncertainty associated with a system in early deployment, applying 233 local policy to eliminate the threat of unroutability of prefixes due 234 to ill-advised certification policies and/or incorrect certification 235 data. E.g. until the community feels comfortable relying on RPKI 236 data, routing on Invalid origin validity, though at a low preference, 237 MAY occur. 239 As origin validation will be rolled out incrementally, coverage will 240 be incomplete for a long time. Therefore, routing on NotFound 241 validity state SHOULD be done for a long time. As the transition 242 moves forward, the number of BGP announcements with validation state 243 NotFound should decrease. Hence an operator's policy SHOULD NOT be 244 overly strict, preferring Valid announcements, attaching a lower 245 preference to, but still using, NotFound announcements, and dropping 246 or giving very low preference to Invalid announcements. 248 Some providers may choose to set Local-Preference based on the RPKI 249 validation result. Other providers may not want the RPKI validation 250 result to be more important than AS-path length -- these providers 251 would need to map RPKI validation result to some BGP attribute that 252 is evaluated in BGP's path selection process after AS-path is 253 evaluated. Routers implementing RPKI-based origin validation MUST 254 provide such options to operators. 256 Local-Preference may be used to carry both the validity state of a 257 prefix along with it's traffic engineering characteristic(s). It is 258 likely that an operator already using Local-Preference will have to 259 change policy so they can encode these two separate characteristics 260 in the same BGP attribute without negatively impact or opening 261 privilege escalation attacks. 263 When using a metric which is also influenced by other local policy, 264 an operator should be careful not to create privilege upgrade 265 vulnerabilities. E.g. if Local Pref is set depending on validity 266 state, be careful that peer community signaling MAY NOT upgrade an 267 Invalid announcement to Valid or better. 269 Announcements with Valid origins SHOULD be preferred over those with 270 NotFound or Invalid origins, if the latter are accepted at all. 272 Announcements with NotFound origins SHOULD be preferred over those 273 with Invalid origins. 275 Announcements with Invalid origins SHOULD NOT be used, but MAY be 276 used to meet special operational needs. In such circumstances, the 277 announcement SHOULD have a lower preference than that given to Valid 278 or NotFound. 280 Validity state signialing SHOULD NOT be accepted from a neighbor AS. 281 The validity state of a received announcement has only local scope 282 due to issues such as scope of trust, RPKI synchrony, and 283 [I-D.ietf-sidr-ltamgmt]. 285 6. Notes 287 Like the DNS, the global RPKI presents only a loosely consistent 288 view, depending on timing, updating, fetching, etc. Thus, one cache 289 or router may have different data about a particular prefix than 290 another cache or router. There is no 'fix' for this, it is the 291 nature of distributed data with distributed caches. 293 It is hoped that testing and deployment will produce advice on 294 relying party cache loading and timing. 296 There is some uncertainty about the origin AS of aggregates and what, 297 if any, ROA can be used. The long range solution to this is the 298 deprecation of AS-SETs, see [I-D.wkumari-deprecate-as-sets]. 300 Operators who manage certificates SHOULD associate RPKI Ghostbusters 301 Records (see [I-D.ietf-sidr-ghostbusters]) with each publication 302 point they control. These are publication points holding the CRL, 303 ROAs, and other signed objects issued by the operator, and made 304 available to other ASs in support of routing on the public Internet. 306 7. Security Considerations 308 As the BGP origin AS of an update is not signed, origin validation is 309 open to malicious spoofing. Therefore, RPKI-based origin validation 310 is designed to deal only with inadvertent mis-advertisement. 312 Origin validation does not address the problem of AS-Path validation. 313 Therefore paths are open to manipulation, either malicious or 314 accidental. 316 As BGP does not ensure that traffic will flow via the paths it 317 advertises, the data plane may not follow the control plane. 319 Be aware of the class of privilege escalation issues discussed in 320 Section 5 above. 322 8. IANA Considerations 324 This document has no IANA Considerations. 326 9. Acknowledgments 328 The author wishes to thank Shane Amante, Rob Austein, Steve Bellovin, 329 Jay Borkenhagen, Steve Kent, Pradosh Mohapatra, Chris Morrow, Sandy 330 Murphy, Keyur Patel, Heather and Jason Schiller, John Scudder, 331 Kotikalapudi Sriram, Maureen Stillman, and Dave Ward. 333 10. References 335 10.1. Normative References 337 [I-D.ietf-sidr-arch] 338 Lepinski, M. and S. Kent, "An Infrastructure to Support 339 Secure Internet Routing", draft-ietf-sidr-arch-13 (work in 340 progress), May 2011. 342 [I-D.ietf-sidr-ghostbusters] 343 Bush, R., "The RPKI Ghostbusters Record", 344 draft-ietf-sidr-ghostbusters-15 (work in progress), 345 October 2011. 347 [I-D.ietf-sidr-ltamgmt] 348 Reynolds, M. and S. Kent, "Local Trust Anchor Management 349 for the Resource Public Key Infrastructure", 350 draft-ietf-sidr-ltamgmt-02 (work in progress), June 2011. 352 [I-D.ietf-sidr-pfx-validate] 353 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 354 Austein, "BGP Prefix Origin Validation", 355 draft-ietf-sidr-pfx-validate-03 (work in progress), 356 October 2011. 358 [I-D.ietf-sidr-repos-struct] 359 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 360 Resource Certificate Repository Structure", 361 draft-ietf-sidr-repos-struct-09 (work in progress), 362 July 2011. 364 [I-D.ietf-sidr-roa-format] 365 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 366 Origin Authorizations (ROAs)", 367 draft-ietf-sidr-roa-format-12 (work in progress), 368 May 2011. 370 [I-D.ietf-sidr-rpki-rtr] 371 Bush, R. and R. Austein, "The RPKI/Router Protocol", 372 draft-ietf-sidr-rpki-rtr-19 (work in progress), 373 October 2011. 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, March 1997. 378 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 379 Scheme", RFC 5781, February 2010. 381 10.2. Informative References 383 [I-D.wkumari-deprecate-as-sets] 384 Kumari, W., "Deprecation of BGP AS_SET, AS_CONFED_SET.", 385 draft-wkumari-deprecate-as-sets-01 (work in progress), 386 September 2010. 388 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 389 Protocol 4 (BGP-4)", RFC 4271, January 2006. 391 [rcynic] "rcynic read-me", 392 . 394 Author's Address 396 Randy Bush 397 Internet Initiative Japan 398 5147 Crystal Springs 399 Bainbridge Island, Washington 98110 400 US 402 Phone: +1 206 780 0431 x1 403 Email: randy@psg.com