idnits 2.17.1 draft-ietf-sidr-bgpsec-ops-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2011) is 4572 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 (-23) exists of draft-ietf-sidr-bgpsec-protocol-00 == 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 (-02) exists of draft-ymbk-rfd-usable-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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 19, 2011 5 Expires: April 21, 2012 7 BGPsec Operational Considerations 8 draft-ietf-sidr-bgpsec-ops-01 10 Abstract 12 Deployment of the BGPsec architecture and protocols has many 13 operational considerations. This document attempts to collect and 14 present them. It is expected to evolve as BGPsec is formalized and 15 initially deployed. 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 April 21, 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. AS/Router Certificates . . . . . . . . . . . . . . . . . . . . 4 61 5. Within a Network . . . . . . . . . . . . . . . . . . . . . . . 4 62 6. Considerations for Edge Sites . . . . . . . . . . . . . . . . . 5 63 7. Beaconing Considerations . . . . . . . . . . . . . . . . . . . 5 64 8. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . 6 65 9. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 68 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 13.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 13.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 BGPsec is a new protocol with many operational considerations. It is 77 expected to be deployed incrementally over a number of years. As 78 core BGPsec-capable routers may require large memory and crypto 79 assist, it is thought that origin validation based on the RPKI will 80 occur over the next two to five years and that BGPsec will start to 81 deploy late in that window. 83 BGPsec relies on widespread propagation of the Resource Public Key 84 Infrastructure (RPKI) [I-D.ietf-sidr-arch]. How the RPKI is 85 distributed and maintained globally and within an operator's 86 infrastructure may be different for BGPsec than for origin 87 validation. 89 BGPsec need be spoken only by a AS's eBGP speaking, AKA border, 90 routers, and is designed so that it can be used to protect 91 announcements which are originated by small edge routers, and this 92 has special operational considerations. 94 Different prefixes have different timing and replay protection 95 considerations. 97 2. Suggested Reading 99 It is assumed that the reader understands BGP, [RFC4271], BGPsec, 100 [I-D.lepinski-bgpsec-overview], the RPKI, see [I-D.ietf-sidr-arch], 101 the RPKI Repository Structure, see [I-D.ietf-sidr-repos-struct], and 102 ROAs, see [I-D.ietf-sidr-roa-format]. 104 3. RPKI Distribution and Maintenance 106 The RPKI is a distributed database containing certificates, CRLs, 107 manifests, ROAs, and Ghostbuster Records as described in 108 [I-D.ietf-sidr-repos-struct]. Policies and considerations for RPKI 109 object generation and maintenance are discussed elsewhere. 111 A local valid cache containing all RPKI data may be gathered from the 112 global distributed database using the rsync protocol and a validation 113 tool such as rcynic. 115 Validated caches may also be created and maintained from other 116 validated caches. Network operators SHOULD take maximum advantage of 117 this feature to minimize load on the global distributed RPKI 118 database. 120 As RPKI-based origin validation relies on the availability of RPKI 121 data, operators SHOULD locate caches close to routers that require 122 these data and services. A router can peer with one or more nearby 123 caches. 125 For redundancy, a router SHOULD peer with more than one cache at the 126 same time. Peering with two or more, at least one local and others 127 remote, is recommended. 129 If an operator trusts upstreams to carry their traffic, they SHOULD 130 also trust the RPKI data those upstreams cache, and SHOULD peer with 131 those caches. Note that this places an obligation on those upstreams 132 to maintain fresh and reliable caches. 134 A transit provider or a network with peers SHOULD validate NLRI in 135 announcements made by upstreams, downstreams, and peers. To minimize 136 impact on the global RPKI, they SHOULD fetch from and then revalidate 137 data from caches provided by their upstreams. 139 An environment where private address space is announced in eBGP the 140 operator MAY have private RPKI objects which cover these private 141 spaces. This will require a trust anchor created and owned by that 142 environment, see [I-D.ietf-sidr-ltamgmt]. 144 4. AS/Router Certificates 146 A site/operator MAY use a single certificate/key in all their 147 routers, one certificate/key per router, or any granularity in 148 between. 150 A large operator, concerned that a compromise of one router's key 151 would make many routers vulnerable, MAY accept a more complex 152 certificate/key distribution burden to reduce this exposure. 154 On the other extreme, an edge site with one or two routers MAY use a 155 single certificate/key. 157 Routers MAY be capable of generating their own keys and having their 158 certificates signed and published in the RPKI by their NOC. This 159 would mean that a router's private key need never leave the router. 161 5. Within a Network 163 BGPsec is spoken by edge routers in a network, those which border 164 other networks/ASs. 166 In a fully BGPsec enabled AS, Route Reflectors MUST have BGPsec 167 enabled if and only if there are eBGP speakers in their client cone. 169 A BGPsec capable router MAY use the data it receives to influence 170 local policy within its network, see Section 8. In deployment this 171 policy should fit into the AS's existing policy, preferences, etc. 172 This allows a network to incrementally deploy BGPsec capable border 173 routers. 175 eBGP speakers which face more critical peers or up/downstreams would 176 be candidates for the earliest deployment. Both securing one's own 177 announcements and validating received announcements should be 178 considered in partial deployment. 180 An eBGP listener MUST NOT trust non-BGPsec markings such as 181 communities received across a trust boundary. 183 6. Considerations for Edge Sites 185 An edge site which does not provide transit and trusts its 186 upstream(s) SHOULD only originate a signed prefix announcement and 187 need not validate received announcements. 189 BGPsec protocol capability negotiation provides for a speaker signing 190 the data it sends but being unable to accept signed data. Thus a 191 smallish edge router may hold only its own signing key(s) and sign 192 it's announcement but not receive signed announcements and therefore 193 not need to deal with the majority of the RPKI. 195 As the vast majority (84%) of ASs are stubs, and they announce the 196 majority of prefixes, this allows for simpler and cheaper early 197 incremental deployment. It may also mean that edge sites concerned 198 with routing security will be attracted to upstreams which support 199 BGPsec. 201 7. Beaconing Considerations 203 The BGPsec protocol attempts to reduce exposure to replay attacks by 204 allowing the route originator to sign an announcement with a validity 205 period and re-announce well within that period. 207 This re-announcement is termed 'beaconing'. All timing values are, 208 of course, jittered. 210 It is only the originator of an NLRI which signs the announcement 211 with a validity period. 213 To reduce vulnerability to a lost beacon announcement, a router 214 SHOULD beacon at a rate somewhat greater than half the signature 215 validity period it uses. 217 As beaconing places a load on the entire global routing system, 218 careful thought MUST be given to any need to beacon frequently. This 219 would be based on a conservative estimation of the vulnerability to a 220 replay attack. 222 Beacon timing and signature validity periods SHOULD be as follows: 224 The Exemplary Citizen: Prefix originators who are not overly 225 concerned about replay attacks might announce with a signature 226 validity of multiple weeks and beacon one third of the validity 227 period. 229 Normal Prefix: Most prefixes SHOULD announce with a signature 230 validity of a week and beacon every three days. 232 Critical Prefix: Of course, we all think what we do is critical. 233 But prefixes of top level DNS servers, and RPKI publication points 234 are actually critical to large swaths of the Internet and are 235 therefore tempting targets for replay attacks. It is suggested 236 that the beaconing of these prefixes SHOULD be two to four hours, 237 with a signature validity of six to twelve hours. 239 Note that this may incur route flap damping (RFD) with current 240 default but deprecated RFD parameters, see [I-D.ymbk-rfd-usable]. 242 8. Routing Policy 244 Unlike origin validation based on the RPKI, BGPsec marks a received 245 announcement as Valid or Invalid, there is no NotFound state. How 246 this is used in routing is up to the operator's local policy. See 247 [I-D.ietf-sidr-pfx-validate]. 249 As BGPsec will be rolled out over years and does not allow for 250 intermediate non-signing edge routers, coverage will be spotty for a 251 long time. Hence a normal operator's policy SHOULD NOT be overly 252 strict, perhaps preferring valid announcements and giving very low 253 preference, but still using, invalid announcements. 255 A BGPsec speaker validates signed paths at the eBGP edge. 257 Local policy on the eBGP edge MAY convey the validation state of a 258 BGP signed path through normal local policy mechanisms, e.g. setting 259 a BGP community, or modifying a metric value such as local-preference 260 or MED. Some MAY choose to use the large Local-Pref hammer. Others 261 MAY choose to let AS-Path rule and set their internal metric, which 262 comes after AS-Path in the BGP decision process. 264 Because of possible RPKI version skew, an AS Path which does not 265 validate at router R0 might validate at R1. Therefore, signed paths 266 that are invalid and yet propagated SHOULD have their signatures kept 267 intact and should be signed if sent to external BGPsec speakers. 269 This implies that updates which a speaker judges to be invalid MAY be 270 propagated to iBGP peers. Therefore, unless local policy ensures 271 otherwise, a signed path learned via iBGP MAY be invalid. If needed, 272 the validation state SHOULD be signaled by normal local policy 273 mechanisms such as communities or metrics. 275 On the other hand, local policy on the eBGP edge might preclude iBGP 276 or eBGP announcement of signed AS Paths which are invalid. 278 If a BGPsec speaker receives an unsigned path, it SHOULD perform 279 origin validation per [I-D.ietf-sidr-pfx-validate]. 281 If it is known that a BGPsec neighbor is not a transparent route 282 server, and the router provides a knob to disallow a received pCount 283 (prepend count, zero for transparent route servers) of zero, that 284 knob SHOULD be applied. 286 9. Notes 288 Like the DNS, the global RPKI presents only a loosely consistent 289 view, depending on timing, updating, fetching, etc. Thus, one cache 290 or router may have different data about a particular prefix than 291 another cache or router. There is no 'fix' for this, it is the 292 nature of distributed data with distributed caches. 294 Operators who manage certificates SHOULD have RPKI Ghostbuster 295 Records (see [I-D.ietf-sidr-ghostbusters]), signed indirectly by End 296 Entity certificates, for those certificates on which others' routing 297 depends for certificate and/or ROA validation. 299 As a router must evaluate certificates and ROAs which are time 300 dependent, routers' clocks MUST be correct to a tolerance of 301 approximately an hour. 303 If a router has reason to believe its clock is seriouly incorrect, 304 e.g. it has a time earlier than 2011, it SHOULD NOT attempt to 305 validate incoming updates. It SHOULD defer validation until it 306 believes it is within reasonable time tolerance. 308 Servers should provide time service, such as NTP [RFC5905], to client 309 routers. 311 10. Security Considerations 313 BGPsec is all about security, routing security. The major security 314 considerations for the protocol are described in 315 [I-D.ietf-sidr-bgpsec-protocol]. 317 11. IANA Considerations 319 This document has no IANA Considerations. 321 12. Acknowledgments 323 The author wishes to thank the BGPsec design team. 325 13. References 327 13.1. Normative References 329 [I-D.ietf-sidr-bgpsec-protocol] 330 Lepinski, M., "BGPSEC Protocol Specification", 331 draft-ietf-sidr-bgpsec-protocol-00 (work in progress), 332 June 2011. 334 [I-D.ietf-sidr-ghostbusters] 335 Bush, R., "The RPKI Ghostbusters Record", 336 draft-ietf-sidr-ghostbusters-15 (work in progress), 337 October 2011. 339 [I-D.ietf-sidr-roa-format] 340 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 341 Origin Authorizations (ROAs)", 342 draft-ietf-sidr-roa-format-12 (work in progress), 343 May 2011. 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 13.2. Informative References 350 [I-D.ietf-sidr-arch] 351 Lepinski, M. and S. Kent, "An Infrastructure to Support 352 Secure Internet Routing", draft-ietf-sidr-arch-13 (work in 353 progress), May 2011. 355 [I-D.ietf-sidr-ltamgmt] 356 Reynolds, M. and S. Kent, "Local Trust Anchor Management 357 for the Resource Public Key Infrastructure", 358 draft-ietf-sidr-ltamgmt-02 (work in progress), June 2011. 360 [I-D.ietf-sidr-pfx-validate] 361 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 362 Austein, "BGP Prefix Origin Validation", 363 draft-ietf-sidr-pfx-validate-02 (work in progress), 364 July 2011. 366 [I-D.ietf-sidr-repos-struct] 367 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 368 Resource Certificate Repository Structure", 369 draft-ietf-sidr-repos-struct-09 (work in progress), 370 July 2011. 372 [I-D.lepinski-bgpsec-overview] 373 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 374 draft-lepinski-bgpsec-overview-00 (work in progress), 375 March 2011. 377 [I-D.ymbk-rfd-usable] 378 Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O. 379 Maennel, "Making Route Flap Damping Usable", 380 draft-ymbk-rfd-usable-01 (work in progress), June 2011. 382 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 383 Protocol 4 (BGP-4)", RFC 4271, January 2006. 385 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 386 Time Protocol Version 4: Protocol and Algorithms 387 Specification", RFC 5905, June 2010. 389 Author's Address 391 Randy Bush 392 Internet Initiative Japan 393 5147 Crystal Springs 394 Bainbridge Island, Washington 98110 395 US 397 Phone: +1 206 780 0431 x1 398 Email: randy@psg.com