idnits 2.17.1 draft-ietf-sidr-bgpsec-ops-09.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 1 instance 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 (June 16, 2016) is 2871 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 (-08) exists of draft-ietf-sidr-bgpsec-overview-02 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-bgpsec-overview (ref. 'I-D.ietf-sidr-bgpsec-overview') == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-07 ** Downref: Normative reference to an Informational RFC: RFC 6480 == Outdated reference: A later version (-12) exists of draft-ietf-idr-ix-bgp-route-server-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: 2 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 June 16, 2016 5 Expires: December 18, 2016 7 BGPsec Operational Considerations 8 draft-ietf-sidr-bgpsec-ops-09 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 December 18, 2016. 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 . . . . . . . . . . . . . . . . . . . . . . . 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 BGPsec, [I-D.ietf-sidr-bgpsec-overview], 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 the 82 next two to three years and that BGPsec will start to deploy well 83 after that. 85 BGPsec relies on widespread propagation of the Resource Public Key 86 Infrastructure (RPKI) [RFC6480]. How the RPKI is distributed and 87 maintained globally and within an operator's infrastructure may be 88 different for BGPsec than for origin validation. 90 BGPsec need be spoken only by an AS's eBGP speaking, AKA border, 91 routers, and is designed so that it can be used to protect 92 announcements which are originated by small edge routers. This has 93 special operational considerations. 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, [RFC4271], BGPsec, 101 [I-D.ietf-sidr-bgpsec-overview], the RPKI, see [RFC6480], the RPKI 102 Repository Structure, see [RFC6481], and ROAs, see [RFC6482]. 104 3. RPKI Distribution and Maintenance 106 All non-ROA considerations in the section on RPKI Distribution and 107 Maintenance of [RFC7115] apply. 109 4. AS/Router Certificates 111 As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers 112 are either capable of generating their own public/private key-pairs 113 and having their certificates signed and published in the RPKI by the 114 RPKI CA system, and/or are given public/private key-pairs by the 115 operator. 117 A site/operator MAY use a single certificate/key in all their 118 routers, one certificate/key per router, or any granularity in 119 between. 121 A large operator, concerned that a compromise of one router's key 122 would make other routers vulnerable, may accept a more complex 123 certificate/key distribution burden to reduce this exposure. 125 On the other extreme, an edge site with one or two routers may choose 126 to use a single certificate/key. 128 In anticipation of possible key compromise, a prudent operator will 129 pre-provision each router's 'next' key in the RPKI so there is no 130 propagation delay for provisioning the new key. 132 5. Within a Network 134 BGPsec is spoken by edge routers in a network, those which border 135 other networks/ASs. 137 In a fully BGPsec enabled AS, Route Reflectors MUST have BGPsec 138 enabled if and only if there are eBGP speakers in their client cone, 139 i.e. an RR client or the transitive closure of their customers' 140 customers' customers' .... 142 A BGPsec capable router MAY use the data it receives to influence 143 local policy within its network, see Section 7. In deployment this 144 policy should fit into the AS's existing policy, preferences, etc. 146 This allows a network to incrementally deploy BGPsec enabled border 147 routers. 149 eBGP speakers which face more critical peers or up/downstreams would 150 be candidates for early deployment. Both securing one's own 151 announcements and validating received announcements should be 152 considered in partial deployment. 154 The operator should be aware that BGPsec, as any other policy change, 155 can cause traffic shifts in their network. And, as with normal 156 policy shift practice, a prudent operator has tools and methods to 157 predict, measure, modify, etc. 159 On the other hand, an operator wanting to monitor router loading, 160 shifts in traffic, etc. might deploy incrementally while watching 161 those and similar effects. 163 As they are not formally verifiable, an eBGP listener SHOULD NOT 164 strongly trust unsigned security markings such as communities 165 received across a trust boundary. 167 6. Considerations for Edge Sites 169 An edge site which does not provide transit and trusts its 170 upstream(s) SHOULD only originate a signed prefix announcement and 171 need not validate received announcements. 173 BGPsec protocol capability negotiation provides for a speaker signing 174 the data it sends without being able to accept signed data. Thus a 175 smallish edge router may hold only its own signing key(s), sign its 176 announcements, but not receive signed announcements and therefore not 177 need to deal with the majority of the RPKI. Thus such routers CPU, 178 RAM, and crypto needs are trivial and additional hardware should not 179 be needed. 181 Operators might need to use hardware with limited resources. In such 182 cases, BGPsec protocol capability negotiation allows for a resource 183 constrained edge router to hold only its own signing key(s) and sign 184 its announcements, but not receive signed announcements. Therefore, 185 the router would not have to deal with the majority of the RPKI, 186 potentially saving the need for additional hardware. 188 As the vast majority (84%) of ASs are stubs, and they announce the 189 majority of prefixes, this allows for simpler and less expensive 190 incremental deployment. It may also mean that edge sites concerned 191 with routing security will be attracted to upstreams which support 192 BGPsec. 194 7. Routing Policy 196 Unlike origin validation based on the RPKI, BGPsec marks a received 197 announcement as Valid or Invalid, there is no explicit NotFound 198 state. In some sense, an unsigned BGP4 path is the equivalent of 199 NotFound. How this is used in routing is up to the operator's local 200 policy. See [RFC6811]. 202 As BGPsec will be rolled out over years and does not allow for 203 intermediate non-signing edge routers, coverage will be spotty for a 204 long time. Hence a normal operator's policy SHOULD NOT be overly 205 strict, perhaps preferring Valid paths and giving very low 206 preference, but still using, Invalid paths. 208 Operators should be aware that accepting Invalid announcements, no 209 matter how de-preffed, will often be the equivalent of treating them 210 as fully Valid. Consider having a Valid announcement from neighbor V 211 for prefix 10.0.0.0/16 and an Invalid announcement for 10.0.666.0/24 212 from neighbor I. If local policy on the router is not configured to 213 discard the Invalid announcement from I, then longest match 214 forwarding will send packets to neighbor I no matter the value of 215 local preference. 217 A BGPsec speaker validates signed paths at the eBGP edge. 219 Local policy on the eBGP edge MAY convey the validation state of a 220 BGP signed path through normal local policy mechanisms, e.g. setting 221 a BGP community for internal use, or modifying a metric value such as 222 local-preference or MED. Some may choose to use the large Local-Pref 223 hammer. Others may choose to let AS-Path rule and set their internal 224 metric, which comes after AS-Path in the BGP decision process. 226 Because of possible RPKI version skew, an AS Path which does not 227 validate at router R0 might validate at R1. Therefore, signed paths 228 that are Invalid and yet propagated (because they are chosen as best 229 path) SHOULD have their signatures kept intact and MUST be signed if 230 sent to external BGPsec speakers. 232 This implies that updates which a speaker judges to be Invalid MAY be 233 propagated to iBGP peers. Therefore, unless local policy ensures 234 otherwise, a signed path learned via iBGP MAY be Invalid. If needed, 235 the validation state should be signaled by normal local policy 236 mechanisms such as communities or metrics. 238 On the other hand, local policy on the eBGP edge might preclude iBGP 239 or eBGP announcement of signed AS Paths which are Invalid. 241 A BGPsec speaker receiving a path SHOULD perform origin validation 242 per [RFC6811] and [RFC7115]. 244 A route server is usually 'transparent', most importantly not 245 inserting its own AS into the AS_Path, to not lengthen the AS hop 246 count and thereby reduce the likelihood of best path selection. See 247 2.2.2 of [I-D.ietf-idr-ix-bgp-route-server]. A BGPsec-aware route 248 server needs to validate the incoming BGPSEC_Path, and to forward 249 updates which can be validated by clients which know the route 250 server's AS. The route server uses pCount of zero to not increase 251 the effective AS hop count. 253 If it is known that a BGPsec neighbor is not a transparent route 254 server, and the router provides a knob to disallow a received pCount 255 (prepend count, zero for transparent route servers) of zero, that 256 knob SHOULD be applied. Routers should default to this knob 257 disallowing pCount 0. 259 To prevent exposure of the internals of BGP Confederations [RFC5065], 260 a BGPsec speaker which is a Member-AS of a Confederation MUST NOT 261 sign updates sent to another Member-AS of the same Confederation. 263 8. Notes 265 For protection from attacks replaying BGP data on the order of a day 266 or longer old, re-keying routers with new keys (previously) 267 provisioned in the RPKI is sufficient. For one approach, see 268 [I-D.ietf-sidr-bgpsec-rollover] 270 Like the DNS, the global RPKI presents only a loosely consistent 271 view, depending on timing, updating, fetching, etc. Thus, one cache 272 or router may have different data about a particular prefix or router 273 than another cache or router. There is no 'fix' for this, it is the 274 nature of distributed data with distributed caches. 276 Operators who manage certificates SHOULD have RPKI GhostBuster 277 Records (see [RFC6493]), signed indirectly by End Entity 278 certificates, for those certificates on which others' routing depends 279 for certificate and/or ROA validation. 281 Operators should be aware of impending algorithm transitions, which 282 will be rare and slow-paced, see [RFC6916]. They should work with 283 their vendors to ensure support for new algorithms. 285 As a router must evaluate certificates and ROAs which are time 286 dependent, routers' clocks MUST be correct to a tolerance of 287 approximately an hour. 289 If a router has reason to believe its clock is seriously incorrect, 290 e.g. it has a time earlier than 2011, it SHOULD NOT attempt to 291 validate incoming updates. It SHOULD defer validation until it 292 believes it is within reasonable time tolerance. 294 Servers should provide time service, such as [RFC5905], to client 295 routers. 297 9. Security Considerations 299 The major security considerations for the BGPsec protocol are 300 described in [I-D.ietf-sidr-bgpsec-protocol]. 302 10. IANA Considerations 304 This document has no IANA Considerations. 306 11. Acknowledgments 308 The author wishes to thank the BGPsec design group, Thomas King, and 309 Arnold Nipper. 311 12. References 313 12.1. Normative References 315 [I-D.ietf-sidr-bgpsec-overview] 316 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 317 draft-ietf-sidr-bgpsec-overview-02 (work in progress), May 318 2012. 320 [I-D.ietf-sidr-bgpsec-protocol] 321 Lepinski, M., "BGPSEC Protocol Specification", draft-ietf- 322 sidr-bgpsec-protocol-07 (work in progress), February 2013. 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, March 1997. 327 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 328 Secure Internet Routing", RFC 6480, February 2012. 330 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 331 Resource Certificate Repository Structure", RFC 6481, 332 February 2012. 334 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 335 Origin Authorizations (ROAs)", RFC 6482, February 2012. 337 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 338 Ghostbusters Record", RFC 6493, February 2012. 340 [RFC7115] Bush, R., "Origin Validation Operation Based on the 341 Resource Public Key Infrastructure (RPKI)", BCP 185, 342 RFC 7115, DOI 10.17487/RFC7115, January 2014, 343 . 345 12.2. Informative References 347 [I-D.ietf-idr-ix-bgp-route-server] 348 Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 349 "Internet Exchange Route Server", draft-ietf-idr-ix-bgp- 350 route-server-02 (work in progress), February 2013. 352 [I-D.ietf-sidr-bgpsec-rollover] 353 Gagliano, R., Patel, K., and B. Weis, "BGPSEC router key 354 rollover as an alternative to beaconing", draft-ietf-sidr- 355 bgpsec-rollover-01 (work in progress), October 2012. 357 [I-D.ietf-sidr-rtr-keying] 358 Turner, S., Patel, K., and R. Bush, "Router Keying for 359 BGPsec", draft-ietf-sidr-rtr-keying-01 (work in progress), 360 February 2013. 362 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 363 Protocol 4 (BGP-4)", RFC 4271, January 2006. 365 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 366 System Confederations for BGP", RFC 5065, August 2007. 368 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 369 Time Protocol Version 4: Protocol and Algorithms 370 Specification", RFC 5905, June 2010. 372 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 373 Austein, "BGP Prefix Origin Validation", RFC 6811, January 374 2013. 376 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 377 Procedure for the Resource Public Key Infrastructure 378 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 379 2013, . 381 Author's Address 383 Randy Bush 384 Internet Initiative Japan 385 5147 Crystal Springs 386 Bainbridge Island, Washington 98110 387 US 389 Email: randy@psg.com