idnits 2.17.1 draft-ietf-sidr-bgpsec-ops-11.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 (December 2, 2016) is 2694 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 == Outdated reference: A later version (-06) exists of draft-ietf-sidr-as-migration-05 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-bgpsec-overview-02 == 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: 0 errors (**), 0 flaws (~~), 8 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 December 2, 2016 5 Expires: June 5, 2017 7 BGPsec Operational Considerations 8 draft-ietf-sidr-bgpsec-ops-11 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 June 5, 2017. 42 Copyright Notice 44 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . 4 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 BGPsec, [I-D.ietf-sidr-bgpsec-protocol], is a new protocol with many 78 operational considerations. It is expected to be deployed 79 incrementally over a number of years. As core BGPsec-capable routers 80 may require large memory and/or modern CPUs, it is thought that 81 origin validation based on the RPKI, [RFC6811], will occur over some 82 years and that BGPsec will start to deploy after that. 84 BGPsec relies on widespread propagation of the Resource Public Key 85 Infrastructure (RPKI) [RFC6480]. How the RPKI is distributed and 86 maintained globally and within an operator's infrastructure may be 87 different for BGPsec than for origin validation. 89 BGPsec needs to be spoken only by an 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 resource constrained edge 92 routers. This has special operational considerations. 94 Different prefixes may have different timing and replay protection 95 considerations. 97 2. Suggested Reading 99 It is assumed that the reader understands BGP, see [RFC4271], BGPsec, 100 [I-D.ietf-sidr-bgpsec-overview], the RPKI, see [RFC6480], the RPKI 101 Repository Structure, see [RFC6481], and ROAs, see [RFC6482]. 103 3. RPKI Distribution and Maintenance 105 All non-ROA considerations in the section on RPKI Distribution and 106 Maintenance of [RFC7115] apply. 108 4. AS/Router Certificates 110 As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers 111 are either capable of generating their own public/private key-pairs 112 and having their certificates signed and published in the RPKI by the 113 RPKI CA system, and/or are given public/private key-pairs by the 114 operator. 116 A site/operator MAY use a single certificate/key in all their 117 routers, one certificate/key per router, or any granularity in 118 between. 120 A large operator, concerned that a compromise of one router's key 121 would make other routers vulnerable, may accept a more complex 122 certificate/key distribution burden to reduce this exposure. 124 On the other extreme, an edge site with one or two routers may choose 125 to use a single certificate/key. 127 In anticipation of possible key compromise, a prudent operator will 128 pre-provision each router's 'next' key in the RPKI so there is no 129 propagation delay for provisioning the new key. 131 5. Within a Network 133 BGPsec is spoken by edge routers in a network, those which border 134 other networks/ASs. 136 In a fully BGPsec enabled AS, Route Reflectors MUST have BGPsec 137 enabled if and only if there are eBGP speakers in their client cone, 138 i.e. an RR client or the transitive closure of a client's customers' 139 customers' customers' etc. 141 A BGPsec capable router MAY use the data it receives to influence 142 local policy within its network, see Section 7. In deployment this 143 policy should fit into the AS's existing policy, preferences, etc. 145 This allows a network to incrementally deploy BGPsec enabled border 146 routers. 148 eBGP speakers which face more critical peers or up/downstreams would 149 be candidates for early deployment. Both securing one's own 150 announcements and validating received announcements should be 151 considered in partial deployment. 153 The operator should be aware that BGPsec, as any other policy change, 154 can cause traffic shifts in their network. And, as with normal 155 policy shift practice, a prudent operator has tools and methods to 156 predict, measure, modify, etc. 158 On the other hand, an operator wanting to monitor router loading, 159 shifts in traffic, etc. might deploy incrementally while watching 160 those and similar effects. 162 BGPsec does not sign over communities, so they are not formally 163 trustable. Additionally, outsourcing verification is not prudent 164 security practice. Therefore an eBGP listener SHOULD NOT strongly 165 trust unsigned security signaling, such as communities, received 166 across a trust boundary. 168 6. Considerations for Edge Sites 170 An edge site which does not provide transit and trusts its 171 upstream(s) SHOULD only originate a signed prefix announcement and 172 need not validate received announcements. 174 Operators might need to use hardware with limited resources. In such 175 cases, BGPsec protocol capability negotiation allows for a resource 176 constrained edge router to hold only its own signing key(s) and sign 177 its announcements, but not receive signed announcements. Therefore, 178 the router would not have to deal with the majority of the RPKI, 179 potentially saving the need for additional hardware. 181 As the vast majority (84%) of ASs are stubs, and they announce the 182 majority of prefixes, this allows for simpler and less expensive 183 incremental deployment. It may also mean that edge sites concerned 184 with routing security will be attracted to upstreams which support 185 BGPsec. 187 7. Routing Policy 189 Unlike origin validation based on the RPKI, BGPsec marks a received 190 announcement as Valid or Not Valid, there is no explicit NotFound 191 state. In some sense, an unsigned BGP4 path is the equivalent of 192 NotFound. How this is used in routing is up to the operator's local 193 policy, similar to origin validation as in [RFC6811]. 195 As BGPsec will be rolled out over years and does not allow for 196 intermediate non-signing edge routers, coverage will be spotty for a 197 long time. This presents a dilemma; should a router evaluating an 198 inbound BGPsec_Path as Not Valid be very strict and discard it? On 199 the other hand, it might be the only path to that prefix, and a very 200 low local-preference would cause it to be used and propagated only if 201 there was no alternative. Either choice is reasonable, but we 202 recommend dropping because of the next point. 204 Operators should be aware that accepting Not Valid announcements, no 205 matter the local preference, will often be the equivalent of treating 206 them as fully Valid. Local preference affects only routes to the 207 same set of destinations. Consider having a Valid announcement from 208 neighbor V for prefix 10.0.0.0/16 and an Not Valid announcement for 209 10.0.666.0/24 from neighbor I. If local policy on the router is not 210 configured to discard the Not Valid announcement from I, then longest 211 match forwarding will send packets to neighbor I no matter the value 212 of local preference. 214 Validation of signed paths is usually deployed at the eBGP edge. 216 Local policy on the eBGP edge MAY convey the validation state of a 217 BGP signed path through normal local policy mechanisms, e.g. setting 218 a BGP community for internal use, or modifying a metric value such as 219 local-preference or MED. Some may choose to use the large Local-Pref 220 hammer. Others may choose to let AS-Path rule and set their internal 221 metric, which comes after AS-Path in the BGP decision process. 223 Because of possible RPKI version skew, an AS Path which does not 224 validate at router R0 might validate at R1. Therefore, signed paths 225 that are Not Valid and yet propagated (because they are chosen as 226 best path) should have their signatures left intact and MUST be 227 signed if sent to external BGPsec speakers. 229 This implies that updates which a speaker judges to be Not Valid MAY 230 be propagated to iBGP peers. Therefore, unless local policy ensures 231 otherwise, a signed path learned via iBGP MAY be Not Valid. If 232 needed, the validation state should be signaled by normal local 233 policy mechanisms such as communities or metrics. 235 On the other hand, local policy on the eBGP edge might preclude iBGP 236 or eBGP announcement of signed AS Paths which are Not Valid. 238 A BGPsec speaker receiving a path SHOULD perform origin validation 239 per [RFC6811] and [RFC7115]. 241 A route server is usually 'transparent', i.e. does not insert an AS 242 into the path so as not to increase the AS hop count and thereby 243 affect downstream path choices. But, with BGPsec, a client router R 244 needs to be able to validate paths which are forward signed to R. 245 But the sending router can not generate signatures to all the 246 possible clients. Therefore a BGPsec-aware route server needs to 247 validate the incoming BGPsec_Path, and to forward updates which can 248 be validated by clients which must therefore know the route server's 249 AS. This implies that the route server creates signatures per client 250 including its own AS in the BGPsec_Path, forward signing to each 251 client AS, see [I-D.ietf-sidr-bgpsec-protocol]. The route server 252 uses pCount of zero to not increase the effective AS hop count, 253 thereby retaining the intent of 'transparency'. 255 If it is known that a BGPsec neighbor is not a transparent route 256 server, or is otherwise validly using pCount=0 (e,g, see 257 [I-D.ietf-sidr-as-migration]), and the router provides a knob to 258 disallow a received pCount (of zero, that knob SHOULD be applied. 259 Routers should disallow pCount 0 by default. 261 To prevent exposure of the internals of BGP Confederations [RFC5065], 262 a BGPsec speaker which is a Member-AS of a Confederation MUST NOT 263 sign updates sent to another Member-AS of the same Confederation. 265 8. Notes 267 For protection from attacks replaying BGP data on the order of a day 268 or longer old, re-keying routers with new keys (previously) 269 provisioned in the RPKI is sufficient. For one approach, see 270 [I-D.ietf-sidr-bgpsec-rollover] 272 Like the DNS, the global RPKI presents only a loosely consistent 273 view, depending on timing, updating, fetching, etc. Thus, one cache 274 or router may have different data about a particular prefix or router 275 than another cache or router. There is no 'fix' for this, it is the 276 nature of distributed data with distributed caches. 278 Operators who manage certificates SHOULD have RPKI GhostBuster 279 Records (see [RFC6493]), signed indirectly by End Entity 280 certificates, for those certificates on which others' routing depends 281 for certificate and/or ROA validation. 283 Operators should be aware of impending algorithm transitions, which 284 will be rare and slow-paced, see [RFC6916]. They should work with 285 their vendors to ensure support for new algorithms. 287 As a router must evaluate certificates and ROAs which are time 288 dependent, routers' clocks MUST be correct to a tolerance of 289 approximately an hour. The common approach is for operators to 290 deploy servers that provide time service, such as [RFC5905], to 291 client routers. 293 If a router has reason to believe its clock is seriously incorrect, 294 e.g. it has a time earlier than 2011, it SHOULD NOT attempt to 295 validate incoming updates. It SHOULD defer validation until it 296 believes it is within reasonable time tolerance. 298 9. Security Considerations 300 This document describes operational considerations for the deployment 301 of BGPsec. The security considerations for BGPsec are described in 302 [I-D.ietf-sidr-bgpsec-protocol]. 304 10. IANA Considerations 306 This document has no IANA Considerations. 308 11. Acknowledgments 310 The author wishes to thank the BGPsec design group, Thomas King, 311 Arnold Nipper, and Alvaro Retana. 313 12. References 315 12.1. Normative References 317 [I-D.ietf-sidr-bgpsec-protocol] 318 Lepinski, M., "BGPSEC Protocol Specification", draft-ietf- 319 sidr-bgpsec-protocol-07 (work in progress), February 2013. 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, March 1997. 324 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 325 Ghostbusters Record", RFC 6493, February 2012. 327 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 328 Austein, "BGP Prefix Origin Validation", RFC 6811, January 329 2013. 331 [RFC7115] Bush, R., "Origin Validation Operation Based on the 332 Resource Public Key Infrastructure (RPKI)", BCP 185, 333 RFC 7115, DOI 10.17487/RFC7115, January 2014, 334 . 336 12.2. Informative References 338 [I-D.ietf-sidr-as-migration] 339 George, W. and S. Murphy, "BGPSec Considerations for AS 340 Migration", draft-ietf-sidr-as-migration-05 (work in 341 progress), April 2016. 343 [I-D.ietf-sidr-bgpsec-overview] 344 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 345 draft-ietf-sidr-bgpsec-overview-02 (work in progress), May 346 2012. 348 [I-D.ietf-sidr-bgpsec-rollover] 349 Gagliano, R., Patel, K., and B. Weis, "BGPSEC router key 350 rollover as an alternative to beaconing", draft-ietf-sidr- 351 bgpsec-rollover-01 (work in progress), October 2012. 353 [I-D.ietf-sidr-rtr-keying] 354 Turner, S., Patel, K., and R. Bush, "Router Keying for 355 BGPsec", draft-ietf-sidr-rtr-keying-01 (work in progress), 356 February 2013. 358 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 359 Protocol 4 (BGP-4)", RFC 4271, January 2006. 361 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 362 System Confederations for BGP", RFC 5065, August 2007. 364 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 365 Time Protocol Version 4: Protocol and Algorithms 366 Specification", RFC 5905, June 2010. 368 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 369 Secure Internet Routing", RFC 6480, February 2012. 371 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 372 Resource Certificate Repository Structure", RFC 6481, 373 February 2012. 375 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 376 Origin Authorizations (ROAs)", RFC 6482, February 2012. 378 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 379 Procedure for the Resource Public Key Infrastructure 380 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 381 2013, . 383 Author's Address 385 Randy Bush 386 Internet Initiative Japan 387 5147 Crystal Springs 388 Bainbridge Island, Washington 98110 389 US 391 Email: randy@psg.com