idnits 2.17.1 draft-ietf-sidr-bgpsec-ops-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2012) is 4430 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-01 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-origin-ops-13 ** 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-03 == Outdated reference: A later version (-01) exists of draft-rogaglia-sidr-bgpsec-rollover-00 Summary: 2 errors (**), 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: BCP March 10, 2012 5 Expires: September 11, 2012 7 BGPsec Operational Considerations 8 draft-ietf-sidr-bgpsec-ops-03 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 September 11, 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 . . . . . . . . . . . . . . . . . 4 63 7. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . 5 64 8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 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.ymbk-bgpsec-rtr-rekeying] routers MAY be capable 108 of 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 5. Within a Network 125 BGPsec is spoken by edge routers in a network, those which border 126 other networks/ASs. 128 In a fully BGPsec enabled AS, Route Reflectors MUST have BGPsec 129 enabled if and only if there are eBGP speakers in their client cone, 130 i.e. an RR client or the transitive closure of their customers' 131 customers' customers' .... 133 A BGPsec capable router MAY use the data it receives to influence 134 local policy within its network, see Section 7. In deployment this 135 policy should fit into the AS's existing policy, preferences, etc. 136 This allows a network to incrementally deploy BGPsec capable border 137 routers. 139 eBGP speakers which face more critical peers or up/downstreams would 140 be candidates for the earliest deployment. Both securing one's own 141 announcements and validating received announcements should be 142 considered in partial deployment. 144 As they are not signed, an eBGP listener SHOULD NOT strongly trust 145 unsigned markings such as communities received across a trust 146 boundary. 148 6. Considerations for Edge Sites 150 An edge site which does not provide transit and trusts its 151 upstream(s) SHOULD only originate a signed prefix announcement and 152 need not validate received announcements. 154 BGPsec protocol capability negotiation provides for a speaker signing 155 the data it sends but being unable to accept signed data. Thus a 156 smallish edge router may hold only its own signing key(s) and sign 157 it's announcement but not receive signed announcements and therefore 158 not need to deal with the majority of the RPKI. Thus such routers 159 CPU, RAM, and crypto needs are trivial and additional hardware should 160 not be needed. 162 As the vast majority (84%) of ASs are stubs, and they announce the 163 majority of prefixes, this allows for simpler and cheaper early 164 incremental deployment. It may also mean that edge sites concerned 165 with routing security will be attracted to upstreams which support 166 BGPsec. 168 7. Routing Policy 170 Unlike origin validation based on the RPKI, BGPsec marks a received 171 announcement as Valid or Invalid, there is no NotFound state. How 172 this is used in routing is up to the operator's local policy. See 173 [I-D.ietf-sidr-pfx-validate]. 175 As BGPsec will be rolled out over years and does not allow for 176 intermediate non-signing edge routers, coverage will be spotty for a 177 long time. Hence a normal operator's policy SHOULD NOT be overly 178 strict, perhaps preferring valid announcements and giving very low 179 preference, but still using, invalid announcements. 181 A BGPsec speaker validates signed paths at the eBGP edge. 183 Local policy on the eBGP edge MAY convey the validation state of a 184 BGP signed path through normal local policy mechanisms, e.g. setting 185 a BGP community, or modifying a metric value such as local-preference 186 or MED. Some MAY choose to use the large Local-Pref hammer. Others 187 MAY choose to let AS-Path rule and set their internal metric, which 188 comes after AS-Path in the BGP decision process. 190 Because of possible RPKI version skew, an AS Path which does not 191 validate at router R0 might validate at R1. Therefore, signed paths 192 that are invalid and yet propagated (because they are chosen as best 193 path) SHOULD have their signatures kept intact and MUST be signed if 194 sent to external BGPsec speakers. 196 This implies that updates which a speaker judges to be invalid MAY be 197 propagated to iBGP peers. Therefore, unless local policy ensures 198 otherwise, a signed path learned via iBGP MAY be invalid. If needed, 199 the validation state SHOULD be signaled by normal local policy 200 mechanisms such as communities or metrics. 202 On the other hand, local policy on the eBGP edge might preclude iBGP 203 or eBGP announcement of signed AS Paths which are invalid. 205 A BGPsec speaker receiving a path SHOULD perform origin validation 206 per [I-D.ietf-sidr-pfx-validate]. 208 If it is known that a BGPsec neighbor is not a transparent route 209 server, and the router provides a knob to disallow a received pCount 210 (prepend count, zero for transparent route servers) of zero, that 211 knob SHOULD be applied. Routers should default to this knob 212 disallowing pCount 0. 214 To prevent exposure of the internals of BGP Confederations [RFC5065], 215 a BGPsec speaker which is a Member-AS of a Confederation MUST NOT 216 sign updates sent to another Member-AS of the same Confederation. 218 8. Notes 220 For protection from attacks replaying BGP data on the order of a day 221 or longer old, re-keying routers with new keys (previously) 222 provisioned in the RPKI is sufficient. For one procedure, see 223 [I-D.rogaglia-sidr-bgpsec-rollover] 225 Like the DNS, the global RPKI presents only a loosely consistent 226 view, depending on timing, updating, fetching, etc. Thus, one cache 227 or router may have different data about a particular prefix than 228 another cache or router. There is no 'fix' for this, it is the 229 nature of distributed data with distributed caches. 231 Operators who manage certificates SHOULD have RPKI Ghostbuster 232 Records (see [I-D.ietf-sidr-ghostbusters]), signed indirectly by End 233 Entity certificates, for those certificates on which others' routing 234 depends for certificate and/or ROA validation. 236 Operators should be aware of impending algorithm transitions, which 237 will be rare and slow-paced, see see 238 [I-D.ietf-sidr-algorithm-agility]. They should work with their 239 vendors to ensure support for new algorithms. 241 As a router must evaluate certificates and ROAs which are time 242 dependent, routers' clocks MUST be correct to a tolerance of 243 approximately an hour. 245 If a router has reason to believe its clock is seriously incorrect, 246 e.g. it has a time earlier than 2011, it SHOULD NOT attempt to 247 validate incoming updates. It SHOULD defer validation until it 248 believes it is within reasonable time tolerance. 250 Servers should provide time service, such as [RFC5905], to client 251 routers. 253 9. Security Considerations 255 The major security considerations for the BGPsec protocol are 256 described in [I-D.ietf-sidr-bgpsec-protocol]. 258 10. IANA Considerations 260 This document has no IANA Considerations. 262 11. References 264 11.1. Normative References 266 [I-D.ietf-sidr-bgpsec-protocol] 267 Lepinski, M., "BGPSEC Protocol Specification", 268 draft-ietf-sidr-bgpsec-protocol-01 (work in progress), 269 October 2011. 271 [I-D.ietf-sidr-ghostbusters] 272 Bush, R., "The RPKI Ghostbusters Record", 273 draft-ietf-sidr-ghostbusters-16 (work in progress), 274 December 2011. 276 [I-D.ietf-sidr-origin-ops] 277 Bush, R., "RPKI-Based Origin Validation Operation", 278 draft-ietf-sidr-origin-ops-13 (work in progress), 279 November 2011. 281 [I-D.lepinski-bgpsec-overview] 282 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 283 draft-lepinski-bgpsec-overview-00 (work in progress), 284 March 2011. 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, March 1997. 289 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 290 Secure Internet Routing", RFC 6480, February 2012. 292 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 293 Resource Certificate Repository Structure", RFC 6481, 294 February 2012. 296 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 297 Origin Authorizations (ROAs)", RFC 6482, February 2012. 299 11.2. Informative References 301 [I-D.ietf-sidr-algorithm-agility] 302 Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 303 Procedure for RPKI.", draft-ietf-sidr-algorithm-agility-05 304 (work in progress), January 2012. 306 [I-D.ietf-sidr-pfx-validate] 307 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 308 Austein, "BGP Prefix Origin Validation", 309 draft-ietf-sidr-pfx-validate-03 (work in progress), 310 October 2011. 312 [I-D.rogaglia-sidr-bgpsec-rollover] 313 Gagliano, R., Patel, K., and B. Weis, "BGPSEC router key 314 roll-over as an alternative to beaconing", 315 draft-rogaglia-sidr-bgpsec-rollover-00 (work in progress), 316 March 2012. 318 [I-D.ymbk-bgpsec-rtr-rekeying] 319 Turner, S., Patel, K., and R. Bush, "Router Keying for 320 BGPsec", draft-ymbk-bgpsec-rtr-rekeying-00 (work in 321 progress), March 2012. 323 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 324 Protocol 4 (BGP-4)", RFC 4271, January 2006. 326 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 327 System Confederations for BGP", RFC 5065, August 2007. 329 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 330 Time Protocol Version 4: Protocol and Algorithms 331 Specification", RFC 5905, June 2010. 333 Author's Address 335 Randy Bush 336 Internet Initiative Japan 337 5147 Crystal Springs 338 Bainbridge Island, Washington 98110 339 US 341 Phone: +1 206 780 0431 x1 342 Email: randy@psg.com