idnits 2.17.1 draft-ietf-sidr-bgpsec-ops-06.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 (July 3, 2015) is 3219 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 (-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 (~~), 7 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 July 3, 2015 5 Expires: January 4, 2016 7 BGPsec Operational Considerations 8 draft-ietf-sidr-bgpsec-ops-06 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 January 4, 2016. 42 Copyright Notice 44 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . 6 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 11.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 BGPsec, [I-D.ietf-sidr-bgpsec-overview], is a new protocol with many 77 operational considerations. It is expected to be deployed 78 incrementally over a number of years. As core BGPsec-capable routers 79 may require large memory and/or modern CPUs, it is thought that 80 origin validation based on the RPKI, [RFC6811], will occur over the 81 next twp to three years and that BGPsec will start to deploy well 82 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 need 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 small edge routers. This has 92 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, [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 their customers' 139 customers' customers' .... 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 As they are not formally verifiable, an eBGP listener SHOULD NOT 163 strongly trust unsigned security markings such as communities 164 received across a trust boundary. 166 6. Considerations for Edge Sites 168 An edge site which does not provide transit and trusts its 169 upstream(s) SHOULD only originate a signed prefix announcement and 170 need not validate received announcements. 172 BGPsec protocol capability negotiation provides for a speaker signing 173 the data it sends without being able to accept signed data. Thus a 174 smallish edge router may hold only its own signing key(s), sign it's 175 announcements, but not receive signed announcements and therefore not 176 need to deal with the majority of the RPKI. Thus such routers CPU, 177 RAM, and crypto needs are trivial and additional hardware should not 178 be needed. 180 As the vast majority (84%) of ASs are stubs, and they announce the 181 majority of prefixes, this allows for simpler and less expensive 182 incremental deployment. It may also mean that edge sites concerned 183 with routing security will be attracted to upstreams which support 184 BGPsec. 186 7. Routing Policy 188 Unlike origin validation based on the RPKI, BGPsec marks a received 189 announcement as Valid or Invalid, there is no explicit NotFound 190 state. In some sense, an unsigned BGP4 path is the equivalent of 191 NotFound. How this is used in routing is up to the operator's local 192 policy. See [RFC6811]. 194 As BGPsec will be rolled out over years and does not allow for 195 intermediate non-signing edge routers, coverage will be spotty for a 196 long time. Hence a normal operator's policy SHOULD NOT be overly 197 strict, perhaps preferring Valid paths and giving very low 198 preference, but still using, Invalid paths. 200 Operators should be aware that accepting Invalid announcements, no 201 matter how de-preffed, will often be the equivalent of treating them 202 as fully Valid. Consider having a Valid announcement from neighbor V 203 for prefix 10.0.0.0/16 and an Invalid announcement for 10.0.666.0/24 204 from neighbor I. If local policy on the router is not configured to 205 discard the Invalid announcement from I, then longest match 206 forwarding will send packets to neighbor I no matter the value of 207 local preference. 209 A BGPsec speaker validates signed paths at the eBGP edge. 211 Local policy on the eBGP edge MAY convey the validation state of a 212 BGP signed path through normal local policy mechanisms, e.g. setting 213 a BGP community for internal use, or modifying a metric value such as 214 local-preference or MED. Some may choose to use the large Local-Pref 215 hammer. Others may choose to let AS-Path rule and set their internal 216 metric, which comes after AS-Path in the BGP decision process. 218 Because of possible RPKI version skew, an AS Path which does not 219 validate at router R0 might validate at R1. Therefore, signed paths 220 that are Invalid and yet propagated (because they are chosen as best 221 path) SHOULD have their signatures kept intact and MUST be signed if 222 sent to external BGPsec speakers. 224 This implies that updates which a speaker judges to be Invalid MAY be 225 propagated to iBGP peers. Therefore, unless local policy ensures 226 otherwise, a signed path learned via iBGP MAY be Invalid. If needed, 227 the validation state should be signaled by normal local policy 228 mechanisms such as communities or metrics. 230 On the other hand, local policy on the eBGP edge might preclude iBGP 231 or eBGP announcement of signed AS Paths which are Invalid. 233 A BGPsec speaker receiving a path SHOULD perform origin validation 234 per [RFC6811] and [RFC7115]. 236 If it is known that a BGPsec neighbor is not a transparent route 237 server, and the router provides a knob to disallow a received pCount 238 (prepend count, zero for transparent route servers) of zero, that 239 knob SHOULD be applied. Routers should default to this knob 240 disallowing pCount 0. 242 To prevent exposure of the internals of BGP Confederations [RFC5065], 243 a BGPsec speaker which is a Member-AS of a Confederation MUST NOT 244 sign updates sent to another Member-AS of the same Confederation. 246 8. Notes 248 For protection from attacks replaying BGP data on the order of a day 249 or longer old, re-keying routers with new keys (previously) 250 provisioned in the RPKI is sufficient. For one approach, see 251 [I-D.ietf-sidr-bgpsec-rollover] 253 Like the DNS, the global RPKI presents only a loosely consistent 254 view, depending on timing, updating, fetching, etc. Thus, one cache 255 or router may have different data about a particular prefix or router 256 than another cache or router. There is no 'fix' for this, it is the 257 nature of distributed data with distributed caches. 259 Operators who manage certificates SHOULD have RPKI GhostBuster 260 Records (see [RFC6493]), signed indirectly by End Entity 261 certificates, for those certificates on which others' routing depends 262 for certificate and/or ROA validation. 264 Operators should be aware of impending algorithm transitions, which 265 will be rare and slow-paced, see see [RFC6916]. They should work 266 with their vendors to ensure support for new algorithms. 268 As a router must evaluate certificates and ROAs which are time 269 dependent, routers' clocks MUST be correct to a tolerance of 270 approximately an hour. 272 If a router has reason to believe its clock is seriously incorrect, 273 e.g. it has a time earlier than 2011, it SHOULD NOT attempt to 274 validate incoming updates. It SHOULD defer validation until it 275 believes it is within reasonable time tolerance. 277 Servers should provide time service, such as [RFC5905], to client 278 routers. 280 9. Security Considerations 282 The major security considerations for the BGPsec protocol are 283 described in [I-D.ietf-sidr-bgpsec-protocol]. 285 10. IANA Considerations 287 This document has no IANA Considerations. 289 11. References 291 11.1. Normative References 293 [I-D.ietf-sidr-bgpsec-overview] 294 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 295 draft-ietf-sidr-bgpsec-overview-02 (work in progress), May 296 2012. 298 [I-D.ietf-sidr-bgpsec-protocol] 299 Lepinski, M., "BGPSEC Protocol Specification", draft-ietf- 300 sidr-bgpsec-protocol-07 (work in progress), February 2013. 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, March 1997. 305 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 306 Secure Internet Routing", RFC 6480, February 2012. 308 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 309 Resource Certificate Repository Structure", RFC 6481, 310 February 2012. 312 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 313 Origin Authorizations (ROAs)", RFC 6482, February 2012. 315 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 316 Ghostbusters Record", RFC 6493, February 2012. 318 [RFC7115] Bush, R., "Origin Validation Operation Based on the 319 Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 320 7115, January 2014. 322 11.2. Informative References 324 [I-D.ietf-sidr-bgpsec-rollover] 325 Gagliano, R., Patel, K., and B. Weis, "BGPSEC router key 326 rollover as an alternative to beaconing", draft-ietf-sidr- 327 bgpsec-rollover-01 (work in progress), October 2012. 329 [I-D.ietf-sidr-rtr-keying] 330 Turner, S., Patel, K., and R. Bush, "Router Keying for 331 BGPsec", draft-ietf-sidr-rtr-keying-01 (work in progress), 332 February 2013. 334 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 335 Protocol 4 (BGP-4)", RFC 4271, January 2006. 337 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 338 System Confederations for BGP", RFC 5065, August 2007. 340 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 341 Time Protocol Version 4: Protocol and Algorithms 342 Specification", RFC 5905, June 2010. 344 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 345 Austein, "BGP Prefix Origin Validation", RFC 6811, January 346 2013. 348 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 349 Procedure for the Resource Public Key Infrastructure 350 (RPKI)", BCP 182, RFC 6916, April 2013. 352 Author's Address 354 Randy Bush 355 Internet Initiative Japan 356 5147 Crystal Springs 357 Bainbridge Island, Washington 98110 358 US 360 Email: randy@psg.com