idnits 2.17.1 draft-ietf-sidr-bgpsec-ops-05.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 date (May 24, 2012) is 4348 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-03 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-origin-ops-15 ** Downref: Normative reference to an Informational draft: draft-lepinski-bgpsec-overview (ref. 'I-D.lepinski-bgpsec-overview') ** Downref: Normative reference to an Informational RFC: RFC 6480 == Outdated reference: A later version (-12) exists of draft-ietf-sidr-algorithm-agility-05 == Outdated reference: A later version (-10) exists of draft-ietf-sidr-pfx-validate-05 == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rtr-keying-00 == Outdated reference: A later version (-01) exists of draft-rogaglia-sidr-bgpsec-rollover-00 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: BCP May 24, 2012 5 Expires: November 25, 2012 7 BGPsec Operational Considerations 8 draft-ietf-sidr-bgpsec-ops-05 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 [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 November 25, 2012. 40 Copyright Notice 42 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . 3 61 5. Within a Network . . . . . . . . . . . . . . . . . . . . . . . 4 62 6. Considerations for Edge Sites . . . . . . . . . . . . . . . . . 5 63 7. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . 5 64 8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 11.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 BGPsec is a new protocol with many operational considerations. It is 75 expected to be deployed incrementally over a number of years. As 76 core BGPsec-capable routers may require large memory and/or modern 77 CPUs, it is thought that origin validation based on the RPKI will 78 occur over the next one to three years and that BGPsec will start to 79 deploy late in that window. 81 BGPsec relies on widespread propagation of the Resource Public Key 82 Infrastructure (RPKI) [RFC6480]. How the RPKI is distributed and 83 maintained globally and within an operator's infrastructure may be 84 different for BGPsec than for origin validation. 86 BGPsec need be spoken only by an AS's eBGP speaking, AKA border, 87 routers, and is designed so that it can be used to protect 88 announcements which are originated by small edge routers. This has 89 special operational considerations. 91 Different prefixes have different timing and replay protection 92 considerations. 94 2. Suggested Reading 96 It is assumed that the reader understands BGP, [RFC4271], BGPsec, 97 [I-D.lepinski-bgpsec-overview], the RPKI, see [RFC6480], the RPKI 98 Repository Structure, see [RFC6481], and ROAs, see [RFC6482]. 100 3. RPKI Distribution and Maintenance 102 All non-ROA considerations in the section on RPKI Distribution and 103 Maintenance of [I-D.ietf-sidr-origin-ops] apply. 105 4. AS/Router Certificates 107 As described in [I-D.ietf-sidr-rtr-keying] routers MAY be capable of 108 generating their own public/private key-pairs and having their 109 certificates signed and published in the RPKI by the RPKI CA system, 110 and/or MAY be given public/private key-pairs by the operator. 112 A site/operator MAY use a single certificate/key in all their 113 routers, one certificate/key per router, or any granularity in 114 between. 116 A large operator, concerned that a compromise of one router's key 117 would make other routers vulnerable, MAY accept a more complex 118 certificate/key distribution burden to reduce this exposure. 120 On the other extreme, an edge site with one or two routers MAY use a 121 single certificate/key. 123 A prudent operator will pre-provision each router's 'next' key in the 124 RPKI so that, in case of compromise of the current key, there is no 125 propagation delay for provisioning the new key. 127 5. Within a Network 129 BGPsec is spoken by edge routers in a network, those which border 130 other networks/ASs. 132 In a fully BGPsec enabled AS, Route Reflectors MUST have BGPsec 133 enabled if and only if there are eBGP speakers in their client cone, 134 i.e. an RR client or the transitive closure of their customers' 135 customers' customers' .... 137 A BGPsec capable router MAY use the data it receives to influence 138 local policy within its network, see Section 7. In deployment this 139 policy should fit into the AS's existing policy, preferences, etc. 140 This allows a network to incrementally deploy BGPsec capable border 141 routers. 143 eBGP speakers which face more critical peers or up/downstreams would 144 be candidates for the earliest deployment. Both securing one's own 145 announcements and validating received announcements should be 146 considered in partial deployment. 148 The operator should be aware that BGPsec, as any other policy change, 149 can cause traffic shifts in their network. And, as with normal 150 policy shift practice, a prudent operator has tools and methods to 151 predict, measure, modify, etc. 153 On the other hand, an operator wanting to monitor router loading, 154 shifts in traffic, etc. will want to deploy incrementally while 155 watching those and similar effects. 157 As they are not signed, an eBGP listener SHOULD NOT strongly trust 158 unsigned markings such as communities received across a trust 159 boundary. 161 6. Considerations for Edge Sites 163 An edge site which does not provide transit and trusts its 164 upstream(s) SHOULD only originate a signed prefix announcement and 165 need not validate received announcements. 167 BGPsec protocol capability negotiation provides for a speaker signing 168 the data it sends but being unable to accept signed data. Thus a 169 smallish edge router may hold only its own signing key(s) and sign 170 it's announcement but not receive signed announcements and therefore 171 not need to deal with the majority of the RPKI. Thus such routers 172 CPU, RAM, and crypto needs are trivial and additional hardware should 173 not be needed. 175 As the vast majority (84%) of ASs are stubs, and they announce the 176 majority of prefixes, this allows for simpler and less expensive 177 incremental deployment. It may also mean that edge sites concerned 178 with routing security will be attracted to upstreams which support 179 BGPsec. 181 7. Routing Policy 183 Unlike origin validation based on the RPKI, BGPsec marks a received 184 announcement as Valid or Invalid, there is no NotFound state. How 185 this is used in routing is up to the operator's local policy. See 186 [I-D.ietf-sidr-pfx-validate]. 188 As BGPsec will be rolled out over years and does not allow for 189 intermediate non-signing edge routers, coverage will be spotty for a 190 long time. Hence a normal operator's policy SHOULD NOT be overly 191 strict, perhaps preferring valid announcements and giving very low 192 preference, but still using, invalid announcements. 194 Operators should be aware that accepting Invalid announcements, no 195 matter how de-preffed, will often be the equivalent of treating them 196 as fully Valid. Consider having a Valid announcement from neighbor V 197 for prefix 10.0.0.0/16 and an Invalid announcement for 10.0.666.0/24 198 from neighbor I. If local policy on the router is not configured to 199 discard the Invalid announcement from I, then longest match 200 forwarding will send packets to neighbor I no matter the value of 201 local preference. 203 A BGPsec speaker validates signed paths at the eBGP edge. 205 Local policy on the eBGP edge MAY convey the validation state of a 206 BGP signed path through normal local policy mechanisms, e.g. setting 207 a BGP community, or modifying a metric value such as local-preference 208 or MED. Some MAY choose to use the large Local-Pref hammer. Others 209 MAY choose to let AS-Path rule and set their internal metric, which 210 comes after AS-Path in the BGP decision process. 212 Because of possible RPKI version skew, an AS Path which does not 213 validate at router R0 might validate at R1. Therefore, signed paths 214 that are invalid and yet propagated (because they are chosen as best 215 path) SHOULD have their signatures kept intact and MUST be signed if 216 sent to external BGPsec speakers. 218 This implies that updates which a speaker judges to be invalid MAY be 219 propagated to iBGP peers. Therefore, unless local policy ensures 220 otherwise, a signed path learned via iBGP MAY be invalid. If needed, 221 the validation state should be signaled by normal local policy 222 mechanisms such as communities or metrics. 224 On the other hand, local policy on the eBGP edge might preclude iBGP 225 or eBGP announcement of signed AS Paths which are invalid. 227 A BGPsec speaker receiving a path SHOULD perform origin validation 228 per [I-D.ietf-sidr-pfx-validate]. 230 If it is known that a BGPsec neighbor is not a transparent route 231 server, and the router provides a knob to disallow a received pCount 232 (prepend count, zero for transparent route servers) of zero, that 233 knob SHOULD be applied. Routers should default to this knob 234 disallowing pCount 0. 236 To prevent exposure of the internals of BGP Confederations [RFC5065], 237 a BGPsec speaker which is a Member-AS of a Confederation MUST NOT 238 sign updates sent to another Member-AS of the same Confederation. 240 8. Notes 242 For protection from attacks replaying BGP data on the order of a day 243 or longer old, re-keying routers with new keys (previously) 244 provisioned in the RPKI is sufficient. For one procedure, see 245 [I-D.rogaglia-sidr-bgpsec-rollover] 247 Like the DNS, the global RPKI presents only a loosely consistent 248 view, depending on timing, updating, fetching, etc. Thus, one cache 249 or router may have different data about a particular prefix than 250 another cache or router. There is no 'fix' for this, it is the 251 nature of distributed data with distributed caches. 253 Operators who manage certificates SHOULD have RPKI Ghostbuster 254 Records (see [I-D.ietf-sidr-ghostbusters]), signed indirectly by End 255 Entity certificates, for those certificates on which others' routing 256 depends for certificate and/or ROA validation. 258 Operators should be aware of impending algorithm transitions, which 259 will be rare and slow-paced, see see 260 [I-D.ietf-sidr-algorithm-agility]. They should work with their 261 vendors to ensure support for new algorithms. 263 As a router must evaluate certificates and ROAs which are time 264 dependent, routers' clocks MUST be correct to a tolerance of 265 approximately an hour. 267 If a router has reason to believe its clock is seriously incorrect, 268 e.g. it has a time earlier than 2011, it SHOULD NOT attempt to 269 validate incoming updates. It SHOULD defer validation until it 270 believes it is within reasonable time tolerance. 272 Servers should provide time service, such as [RFC5905], to client 273 routers. 275 9. Security Considerations 277 The major security considerations for the BGPsec protocol are 278 described in [I-D.ietf-sidr-bgpsec-protocol]. 280 10. IANA Considerations 282 This document has no IANA Considerations. 284 11. References 286 11.1. Normative References 288 [I-D.ietf-sidr-bgpsec-protocol] 289 Lepinski, M., "BGPSEC Protocol Specification", 290 draft-ietf-sidr-bgpsec-protocol-03 (work in progress), 291 May 2012. 293 [I-D.ietf-sidr-ghostbusters] 294 Bush, R., "The RPKI Ghostbusters Record", 295 draft-ietf-sidr-ghostbusters-16 (work in progress), 296 December 2011. 298 [I-D.ietf-sidr-origin-ops] 299 Bush, R., "RPKI-Based Origin Validation Operation", 300 draft-ietf-sidr-origin-ops-15 (work in progress), 301 March 2012. 303 [I-D.lepinski-bgpsec-overview] 304 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 305 draft-lepinski-bgpsec-overview-00 (work in progress), 306 March 2011. 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14, RFC 2119, March 1997. 311 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 312 Secure Internet Routing", RFC 6480, February 2012. 314 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 315 Resource Certificate Repository Structure", RFC 6481, 316 February 2012. 318 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 319 Origin Authorizations (ROAs)", RFC 6482, February 2012. 321 11.2. Informative References 323 [I-D.ietf-sidr-algorithm-agility] 324 Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 325 Procedure for RPKI.", draft-ietf-sidr-algorithm-agility-05 326 (work in progress), January 2012. 328 [I-D.ietf-sidr-pfx-validate] 329 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 330 Austein, "BGP Prefix Origin Validation", 331 draft-ietf-sidr-pfx-validate-05 (work in progress), 332 April 2012. 334 [I-D.ietf-sidr-rtr-keying] 335 Turner, S., Patel, K., and R. Bush, "Router Keying for 336 BGPsec", draft-ietf-sidr-rtr-keying-00 (work in progress), 337 May 2012. 339 [I-D.rogaglia-sidr-bgpsec-rollover] 340 Gagliano, R., Patel, K., and B. Weis, "BGPSEC router key 341 roll-over as an alternative to beaconing", 342 draft-rogaglia-sidr-bgpsec-rollover-00 (work in progress), 343 March 2012. 345 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 346 Protocol 4 (BGP-4)", RFC 4271, January 2006. 348 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 349 System Confederations for BGP", RFC 5065, August 2007. 351 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 352 Time Protocol Version 4: Protocol and Algorithms 353 Specification", RFC 5905, June 2010. 355 Author's Address 357 Randy Bush 358 Internet Initiative Japan 359 5147 Crystal Springs 360 Bainbridge Island, Washington 98110 361 US 363 Phone: +1 206 780 0431 x1 364 Email: randy@psg.com