idnits 2.17.1 draft-ietf-sidr-bgpsec-ops-16.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 2 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 document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 5, 2017) is 2630 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-07 ** Obsolete normative reference: RFC 7730 (Obsoleted by RFC 8630) == Outdated reference: A later version (-06) exists of draft-ietf-sidr-bgpsec-rollover-01 == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rtr-keying-01 Summary: 1 error (**), 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: Best Current Practice January 5, 2017 5 Expires: July 9, 2017 7 BGPsec Operational Considerations 8 draft-ietf-sidr-bgpsec-ops-16 10 Abstract 12 Deployment of the BGPsec architecture and protocols has many 13 operational considerations. This document attempts to collect and 14 present the most critical and universal. It is expected to evolve as 15 BGPsec is formalized and initially deployed. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 21 be interpreted as described in RFC 2119 [RFC2119] only when they 22 appear in all upper case. They may also appear in lower or mixed 23 case as English words, without normative meaning. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 9, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3 61 3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . 3 62 4. AS/Router Certificates . . . . . . . . . . . . . . . . . . . 3 63 5. Within a Network . . . . . . . . . . . . . . . . . . . . . . 3 64 6. Considerations for Edge Sites . . . . . . . . . . . . . . . . 4 65 7. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 5 66 8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 12.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Origin Validation based on the Resource Public Key Infrastructure 78 (RPKI), [RFC6811], is in its early phases. As BGPsec, 79 [I-D.ietf-sidr-bgpsec-protocol] may require larger memory and/or more 80 modern CPUs, it expected to be deployed incrementally over a longer 81 time span. BGPsec is a new protocol with many operational 82 considerations which this document attempts to describe. As with 83 most operational practices, this document will likely evolve. 85 BGPsec relies on widespread propagation of the RPKI [RFC6480]. How 86 the RPKI is distributed and maintained globally and within an 87 operator's infrastructure may be different for BGPsec than for origin 88 validation. 90 BGPsec needs to be spoken only by an AS's eBGP-speaking border 91 routers. It is designed so that it can be used to protect 92 announcements which are originated by resource constrained edge 93 routers. This has special operational considerations, see Section 6. 95 Different prefixes may have different timing and replay protection 96 considerations. 98 2. Suggested Reading 100 It is assumed that the reader understands BGP, see [RFC4271], BGPsec, 101 [I-D.ietf-sidr-bgpsec-protocol], the RPKI, see [RFC6480], the RPKI 102 Repository Structure, see [RFC6481], and Route Origin Authorizations 103 (ROAs), see [RFC6482]. 105 3. RPKI Distribution and Maintenance 107 The considerations for RPKI objects (Certificates, Certificate 108 Revocation Lists (CRLs), manifests, Ghostbusters Records [RFC6481]), 109 Trust Anchor Locators (TALs) [RFC7730], cache behaviours of 110 synchronisation and validation from the section on RPKI Distribution 111 and Maintenance of [RFC7115] apply. Specific considerations relating 112 to ROA objects do not apply to this document. 114 4. AS/Router Certificates 116 As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers 117 are capable of generating their own public/private key-pairs and 118 having their certificates signed and published in the RPKI by the 119 RPKI CA system, and/or are given public/private key-pairs by the 120 operator. 122 A site/operator may use a single certificate/key in all their 123 routers, one certificate/key per router, or any granularity in 124 between. 126 A large operator, concerned that a compromise of one router's key 127 would make other routers vulnerable, may deploy a more complex 128 certificate/key distribution burden to reduce this exposure. 130 At the other end of the spectrum, an edge site with one or two 131 routers may choose to use a single certificate/key. 133 In anticipation of possible key compromise, a prudent operator SHOULD 134 pre-provision each router's 'next' key in the RPKI so there is no 135 propagation delay for provisioning the new key. 137 5. Within a Network 139 BGPsec is spoken by edge routers in a network, those which border 140 other networks/ASs. 142 In an AS where edge routers speak BGPsec and therefore inject BGPsec 143 paths into the iBGP, Route Reflectors MUST have BGPsec enabled if and 144 only if there are eBGP speakers in their client cone, i.e. an RR 145 client or the transitive closure of a client's customers. 147 A BGPsec capable router MAY use the data it receives to influence 148 local policy within its network, see Section 7. In deployment this 149 policy should fit into the AS's existing policy, preferences, etc. 150 This allows a network to incrementally deploy BGPsec enabled border 151 routers. 153 eBGP speakers which face more critical peers or up/downstreams would 154 be candidates for early deployment. Both securing one's own 155 announcements and validating received announcements should be 156 considered in partial deployment. 158 An operator should be aware that BGPsec, as any other policy change, 159 can cause traffic shifts in their network. And, as with normal 160 policy shift practice, a prudent operator has tools and methods to 161 predict, measure, modify, etc. 163 On the other hand, an operator wanting to monitor router loading, 164 shifts in traffic, etc. might deploy incrementally while watching 165 those and similar effects. 167 BGPsec does not sign over communities, so they are not formally 168 trustable. Additionally, outsourcing verification is not prudent 169 security practice. Therefore an eBGP listener SHOULD NOT strongly 170 trust unsigned security signaling, such as communities, received 171 across a trust boundary. 173 6. Considerations for Edge Sites 175 An edge site which does not provide transit and trusts its 176 upstream(s) may only originate a signed prefix announcement and not 177 validate received announcements. 179 An Operator might need to use hardware with limited resources. In 180 such cases, BGPsec protocol capability negotiation allows for a 181 resource constrained edge router to hold only its own signing key(s) 182 and sign its announcements, but not receive signed announcements. 183 Therefore, the router would not have to deal with the majority of the 184 RPKI, potentially saving the need for additional hardware. 186 As the vast majority of ASs are stubs, and they announce the majority 187 of prefixes, this allows for simpler and less expensive incremental 188 deployment. It may also mean that edge sites concerned with routing 189 security will be attracted to upstreams which support BGPsec. 191 7. Routing Policy 193 Unlike origin validation based on the RPKI, BGPsec marks a received 194 announcement as Valid or Not Valid, there is no explicit NotFound 195 state. In some sense, an unsigned BGP4 path is the equivalent of 196 NotFound. How this is used in routing is up to the operator's local 197 policy, similar to origin validation as in [RFC6811]. 199 As BGPsec will be rolled out over years and does not allow for 200 intermediate non-signing edge routers, coverage will be spotty for a 201 long time. This presents a dilemma; should a router evaluating an 202 inbound BGPsec_Path as Not Valid be very strict and discard it? On 203 the other hand, it might be the only path to that prefix, and a very 204 low local-preference would cause it to be used and propagated only if 205 there was no alternative. Either choice is reasonable, but we 206 recommend dropping because of the next point. 208 Operators should be aware that accepting Not Valid announcements, no 209 matter the local preference, will often be the equivalent of treating 210 them as fully Valid. Local preference affects only routes to the 211 same set of destinations. Consider having a Valid announcement from 212 neighbor V for prefix 10.0.0.0/16 and an Not Valid announcement for 213 10.0.666.0/24 from neighbor I. If local policy on the router is not 214 configured to discard the Not Valid announcement from I, then longest 215 match forwarding will send packets to neighbor I no matter the value 216 of local preference. 218 Validation of signed paths is usually deployed at the eBGP edge. 220 Local policy on the eBGP edge MAY convey the validation state of a 221 BGP signed path through normal local policy mechanisms, e.g. setting 222 a BGP community for internal use, or modifying a metric value such as 223 local-preference or multi-exit discriminator (MED). Some may choose 224 to use the large Local-Pref hammer. Others may choose to let AS-Path 225 rule and set their internal metric, which comes after AS-Path in the 226 BGP decision process. 228 As the mildly stochastic timing of RPKI propagation may cause version 229 skew across routers, an AS Path which does not validate at router R0 230 might validate at R1. Therefore, signed paths that are Not Valid and 231 yet propagated (because they are chosen as best path) MUST NOT have 232 signatures stripped and MUST be signed if sent to external BGPsec 233 speakers. 235 This implies that updates which a speaker judges to be Not Valid MAY 236 be propagated to iBGP peers. Therefore, unless local policy ensures 237 otherwise, a signed path learned via iBGP may be Not Valid. If 238 needed, the validation state should be signaled by normal local 239 policy mechanisms such as communities or metrics. 241 On the other hand, local policy on the eBGP edge might preclude iBGP 242 or eBGP announcement of signed AS Paths which are Not Valid. 244 A BGPsec speaker receiving a path SHOULD perform origin validation 245 per [RFC6811] and [RFC7115]. 247 A route server is usually 'transparent', i.e. does not insert an AS 248 into the path so as not to increase the AS hop count and thereby 249 affect downstream path choices. But, with BGPsec, a client router R 250 needs to be able to validate paths which are forward signed to R. 251 But the sending router can not generate signatures to all the 252 possible clients. Therefore a BGPsec-aware route server needs to 253 validate the incoming BGPsec_Path, and to forward updates which can 254 be validated by clients which must therefore know the route server's 255 AS. This implies that the route server creates signatures per client 256 including its own AS in the BGPsec_Path, forward signing to each 257 client AS, see [I-D.ietf-sidr-bgpsec-protocol]. The route server 258 uses pCount of zero to not increase the effective AS hop count, 259 thereby retaining the intent of 'transparency'. 261 If it is known that a BGPsec neighbor is not a transparent route 262 server, or is otherwise validly using pCount=0 (e,g, see 263 [I-D.ietf-sidr-as-migration]), and the router provides a knob to 264 disallow a received pCount (of zero, that knob SHOULD be applied. 265 Routers should disallow pCount 0 by default. 267 To prevent exposure of the internals of BGP Confederations [RFC5065], 268 a BGPsec speaker exporting to a non-member removes all intra- 269 confederation Secure_Path segments. Therefore signing within the 270 confederation will not cause external confusion even if non-unique 271 private ASs are used. 273 8. Notes 275 For protection from attacks replaying BGP data on the order of a day 276 or longer old, re-keying routers with new keys (previously) 277 provisioned in the RPKI is sufficient. For one approach, see 278 [I-D.ietf-sidr-bgpsec-rollover] 280 A router that once negotiated (and/or sent) BGPsec should not be 281 expected to always do so. 283 Like the DNS, the global RPKI presents only a loosely consistent 284 view, depending on timing, updating, fetching, etc. Thus, one cache 285 or router may have different data about a particular prefix or router 286 than another cache or router. There is no 'fix' for this, it is the 287 nature of distributed data with distributed caches. 289 Operators who manage certificates SHOULD have RPKI GhostBuster 290 Records (see [RFC6493]), signed indirectly by End Entity 291 certificates, for those certificates on which others' routing depends 292 for certificate and/or ROA validation. 294 Operators should be aware of impending algorithm transitions, which 295 will be rare and slow-paced, see [RFC6916]. They should work with 296 their vendors to ensure support for new algorithms. 298 As a router must evaluate certificates and ROAs which are time 299 dependent, routers' clocks MUST be correct to a tolerance of 300 approximately an hour. The common approach is for operators to 301 deploy servers that provide time service, such as [RFC5905], to 302 client routers. 304 If a router has reason to believe its clock is seriously incorrect, 305 e.g. it has a time earlier than 2011, it SHOULD NOT attempt to 306 validate incoming updates. It SHOULD defer validation until it 307 believes it is within reasonable time tolerance. 309 9. Security Considerations 311 This document describes operational considerations for the deployment 312 of BGPsec. The security considerations for BGPsec are described in 313 [I-D.ietf-sidr-bgpsec-protocol]. 315 10. IANA Considerations 317 This document has no IANA Considerations. 319 11. Acknowledgments 321 The author wishes to thank Thomas King, Arnold Nipper, and Alvaro 322 Retana, and the BGPsec design group. 324 12. References 326 12.1. Normative References 328 [I-D.ietf-sidr-bgpsec-protocol] 329 Lepinski, M., "BGPSEC Protocol Specification", draft-ietf- 330 sidr-bgpsec-protocol-07 (work in progress), February 2013. 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, March 1997. 335 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 336 Ghostbusters Record", RFC 6493, February 2012. 338 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 339 Austein, "BGP Prefix Origin Validation", RFC 6811, January 340 2013. 342 [RFC7115] Bush, R., "Origin Validation Operation Based on the 343 Resource Public Key Infrastructure (RPKI)", BCP 185, 344 RFC 7115, DOI 10.17487/RFC7115, January 2014, 345 . 347 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 348 "Resource Public Key Infrastructure (RPKI) Trust Anchor 349 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 350 . 352 12.2. Informative References 354 [I-D.ietf-sidr-as-migration] 355 George, W. and S. Murphy, "BGPSec Considerations for AS 356 Migration", draft-ietf-sidr-as-migration-06 (work in 357 progress), December 2016. 359 [I-D.ietf-sidr-bgpsec-rollover] 360 Gagliano, R., Patel, K., and B. Weis, "BGPSEC router key 361 rollover as an alternative to beaconing", draft-ietf-sidr- 362 bgpsec-rollover-01 (work in progress), October 2012. 364 [I-D.ietf-sidr-rtr-keying] 365 Turner, S., Patel, K., and R. Bush, "Router Keying for 366 BGPsec", draft-ietf-sidr-rtr-keying-01 (work in progress), 367 February 2013. 369 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 370 Protocol 4 (BGP-4)", RFC 4271, January 2006. 372 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 373 System Confederations for BGP", RFC 5065, August 2007. 375 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 376 Time Protocol Version 4: Protocol and Algorithms 377 Specification", RFC 5905, June 2010. 379 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 380 Secure Internet Routing", RFC 6480, February 2012. 382 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 383 Resource Certificate Repository Structure", RFC 6481, 384 February 2012. 386 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 387 Origin Authorizations (ROAs)", RFC 6482, February 2012. 389 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 390 Procedure for the Resource Public Key Infrastructure 391 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 392 2013, . 394 Author's Address 396 Randy Bush 397 Internet Initiative Japan 398 5147 Crystal Springs 399 Bainbridge Island, Washington 98110 400 US 402 Email: randy@psg.com