idnits 2.17.1 draft-ietf-sidr-origin-ops-12.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 (October 31, 2011) is 4561 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-02 == Outdated reference: A later version (-26) exists of draft-ietf-sidr-rpki-rtr-18 ** 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 October 31, 2011 5 Expires: May 3, 2012 7 RPKI-Based Origin Validation Operation 8 draft-ietf-sidr-origin-ops-12 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 3, 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 . . . . . . . . . . . . . . . . . . . . 7 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 RPKI-based origin validation relies on the availability of RPKI 131 data, operators SHOULD locate caches close to routers that require 132 these data and services. 'Close' is, of course, complex. One should 133 consider trust boundaries, routing bootstrap reachability, latency, 134 etc. 136 For redundancy, a router SHOULD peer with more than one cache at the 137 same time. Peering with two or more, at least one local and others 138 remote, is recommended. 140 If an operator trusts upstreams to carry their traffic, they MAY also 141 trust the RPKI data those upstreams cache, and SHOULD peer with 142 caches made available to them by those upstreams. Note that this 143 places an obligation on those upstreams to maintain fresh and 144 reliable caches, and to make them available to their customers. And, 145 as usual, the recipient SHOULD re-validate the data. 147 A transit provider or a network with peers SHOULD validate origins in 148 announcements made by upstreams, down-streams, and peers. They still 149 SHOULD trust the caches provided by their upstreams. 151 Before issuing a ROA for a super-block, an operator MUST ensure that 152 any sub-allocations from that block which are announced by other ASs, 153 e.g. customers, have correct ROAs in the RPKI. Otherwise, issuing a 154 ROA for the super-block will cause the announcements of sub- 155 allocations with no ROAs to be viewed as Invalid, see 156 [I-D.ietf-sidr-pfx-validate]. 158 Use of RPKI-based origin validation removes any need to originate 159 more specifics into BGP to protect against mis-origination of a less 160 specific prefix. Having a ROA for the covering prefix should protect 161 it. 163 To aid translation of ROAs into efficient search algorithms in 164 routers, ROAs SHOULD be as precise as possible, i.e. match prefixes 165 as announced in BGP. E.g. software and operators SHOULD avoid use of 166 excessive max length values in ROAs unless operationally necessary. 168 One advantage of minimal ROA length is that the forged origin attack 169 does not work for sub-prefixes that are not covered by overly long 170 max length. E.g. if, instead of 10.0.0.0/16-24, one issues 171 10.0.0.0/16 and 10.0.42.0/24, a forged origin attack can not succeed 172 against 10.0.66.0/24. They must attack the whole /16, which is more 173 likely to be noticed. 175 Therefore, ROA generation software MUST use the prefix length as the 176 max length if the user does not specify a max length. 178 Operators SHOULD be conservative in use of max length in ROAs. E.g., 179 if a prefix will have only a few sub-prefixes announced, multiple 180 ROAs for the specific announcements SHOULD be used as opposed to one 181 ROA with a long max length. 183 If a prefix is legitimately announced by more than one AS, ROAs for 184 all of the ASs SHOULD be issued so that all are considered Valid. 186 An environment where private address space is announced in eBGP the 187 operator MAY have private RPKI objects which cover these private 188 spaces. This will require a trust anchor created and owned by that 189 environment, see [I-D.ietf-sidr-ltamgmt]. 191 Operators owning prefix P should issue ROAs for all ASs which may 192 announce P. 194 Operators issuing ROAs may have customers which announce their own 195 prefixes and ASs into global eBGP but who do not wish to go though 196 the work to manage the relevant certificates and ROAs. Operators 197 SHOULD offer to provision the RPKI data for these customers just as 198 they provision many other things for them. 200 While an operator using RPKI data MAY choose any polling frequency 201 they wish for ensuring they have a fresh RPKI cache. However, if 202 they use RPKI data as an input to operational routing decisions, they 203 SHOULD ensure local cache freshness at least every four to six hours. 205 4. Within a Network 207 Origin validation need only be done by edge routers in a network, 208 those which border other networks/ASs. 210 A validating router will use the result of origin validation to 211 influence local policy within its network, see Section 5. In 212 deployment this policy should fit into the AS's existing policy, 213 preferences, etc. This allows a network to incrementally deploy 214 validation-capable border routers. 216 eBGP speakers which face more critical peers or up/down-streams are 217 candidates for the earliest deployment. Validating more critical 218 received announcements should be considered in partial deployment. 220 5. Routing Policy 222 Origin validation based on the RPKI marks a received announcement as 223 having an origin which is Valid, NotFound, or Invalid. See 224 [I-D.ietf-sidr-pfx-validate]. How this is used in routing SHOULD be 225 specified by the operator's local policy. 227 Local policy using relative preference is suggested to manage the 228 uncertainty associated with a system in early deployment, applying 229 local policy to eliminate the threat of unroutability of prefixes due 230 to ill-advised certification policies and/or incorrect certification 231 data. E.g. until the community feels comfortable relying on RPKI 232 data, routing on Invalid origin validity, though at a low preference, 233 MAY occur. 235 As origin validation will be rolled out incrementally, coverage will 236 be incomplete for a long time. Therefore, routing on NotFound 237 validity state SHOULD be done for a long time. As the transition 238 moves forward, the number of BGP announcements with validation state 239 NotFound should decrease. Hence an operator's policy SHOULD NOT be 240 overly strict, preferring Valid announcements, attaching a lower 241 preference to, but still using, NotFound announcements, and dropping 242 or giving very low preference to Invalid announcements. 244 Some providers may choose to set Local-Preference based on the RPKI 245 validation result. Other providers may not want the RPKI validation 246 result to be more important than AS-path length -- these providers 247 would need to map RPKI validation result to some BGP attribute that 248 is evaluated in BGP's path selection process after AS-path is 249 evaluated. Routers implementing RPKI-based origin validation MUST 250 provide such options to operators. 252 When using a metric which is also influenced by other local policy, 253 an operator should be careful not to create privilege upgrade 254 vulnerabilities. E.g. if Local Pref is set depending on validity 255 state, be careful that peer community signaling MAY NOT upgrade an 256 Invalid announcement to Valid or better. 258 Announcements with Valid origins SHOULD be preferred over those with 259 NotFound or Invalid origins, if the latter are accepted at all. 261 Announcements with NotFound origins SHOULD be preferred over those 262 with Invalid origins. 264 Announcements with Invalid origins SHOULD NOT be used, but MAY be 265 used to meet special operational needs. In such circumstances, the 266 announcement SHOULD have a lower preference than that given to Valid 267 or NotFound. 269 Validity state signialing SHOULD NOT be accepted from a neighbor AS. 270 The validity state of a received announcement has only local scope 271 due to issues such as scope of trust, RPKI synchrony, and 272 [I-D.ietf-sidr-ltamgmt]. 274 6. Notes 276 Like the DNS, the global RPKI presents only a loosely consistent 277 view, depending on timing, updating, fetching, etc. Thus, one cache 278 or router may have different data about a particular prefix than 279 another cache or router. There is no 'fix' for this, it is the 280 nature of distributed data with distributed caches. 282 There is some uncertainty about the origin AS of aggregates and what, 283 if any, ROA can be used. The long range solution to this is the 284 deprecation of AS-SETs, see [I-D.wkumari-deprecate-as-sets]. 286 Operators who manage certificates SHOULD associate RPKI Ghostbusters 287 Records (see [I-D.ietf-sidr-ghostbusters]) with each publication 288 point they control. These are publication points holding the CRL, 289 ROAs, and other signed objects issued by the operator, and made 290 available to other ASs in support of routing on the public Internet. 292 7. Security Considerations 294 As the BGP origin AS of an update is not signed, origin validation is 295 open to malicious spoofing. Therefore, RPKI-based origin validation 296 is designed to deal only with inadvertent mis-advertisement. 298 Origin validation does not address the problem of AS-Path validation. 299 Therefore paths are open to manipulation, either malicious or 300 accidental. 302 As BGP does not ensure that traffic will flow via the paths it 303 advertises, the data plane may not follow the control plane. 305 Be aware of the class of privilege escalation issues discussed in 306 Section 5 above. 308 8. IANA Considerations 310 This document has no IANA Considerations. 312 9. Acknowledgments 314 The author wishes to thank Rob Austein, Steve Bellovin, Jay 315 Borkenhagen, Steve Kent, Pradosh Mohapatra, Chris Morrow, Sandy 316 Murphy, Keyur Patel, Heather and Jason Schiller, John Scudder, 317 Kotikalapudi Sriram, Maureen Stillman, and Dave Ward. 319 10. References 321 10.1. Normative References 323 [I-D.ietf-sidr-arch] 324 Lepinski, M. and S. Kent, "An Infrastructure to Support 325 Secure Internet Routing", draft-ietf-sidr-arch-13 (work in 326 progress), May 2011. 328 [I-D.ietf-sidr-ghostbusters] 329 Bush, R., "The RPKI Ghostbusters Record", 330 draft-ietf-sidr-ghostbusters-15 (work in progress), 331 October 2011. 333 [I-D.ietf-sidr-ltamgmt] 334 Reynolds, M. and S. Kent, "Local Trust Anchor Management 335 for the Resource Public Key Infrastructure", 336 draft-ietf-sidr-ltamgmt-02 (work in progress), June 2011. 338 [I-D.ietf-sidr-pfx-validate] 339 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 340 Austein, "BGP Prefix Origin Validation", 341 draft-ietf-sidr-pfx-validate-02 (work in progress), 342 July 2011. 344 [I-D.ietf-sidr-repos-struct] 345 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 346 Resource Certificate Repository Structure", 347 draft-ietf-sidr-repos-struct-09 (work in progress), 348 July 2011. 350 [I-D.ietf-sidr-roa-format] 351 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 352 Origin Authorizations (ROAs)", 353 draft-ietf-sidr-roa-format-12 (work in progress), 354 May 2011. 356 [I-D.ietf-sidr-rpki-rtr] 357 Bush, R. and R. Austein, "The RPKI/Router Protocol", 358 draft-ietf-sidr-rpki-rtr-18 (work in progress), 359 October 2011. 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 365 Scheme", RFC 5781, February 2010. 367 10.2. Informative References 369 [I-D.wkumari-deprecate-as-sets] 370 Kumari, W., "Deprecation of BGP AS_SET, AS_CONFED_SET.", 371 draft-wkumari-deprecate-as-sets-01 (work in progress), 372 September 2010. 374 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 375 Protocol 4 (BGP-4)", RFC 4271, January 2006. 377 [rcynic] "rcynic read-me", 378 . 380 Author's Address 382 Randy Bush 383 Internet Initiative Japan 384 5147 Crystal Springs 385 Bainbridge Island, Washington 98110 386 US 388 Phone: +1 206 780 0431 x1 389 Email: randy@psg.com