idnits 2.17.1 draft-ietf-sidr-bgpsec-ops-02.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 8, 2012) is 4431 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 ** 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 (-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 (~~), 4 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 8, 2012 5 Expires: September 9, 2012 7 BGPsec Operational Considerations 8 draft-ietf-sidr-bgpsec-ops-02 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 9, 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 . . . . . . . . . . . . . . . . . . 7 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-pfx-validate] 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 (the transitive closure of their customers' customers' customers' 131 ...). 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 As a router must evaluate certificates and ROAs which are time 237 dependent, routers' clocks MUST be correct to a tolerance of 238 approximately an hour. 240 If a router has reason to believe its clock is seriously incorrect, 241 e.g. it has a time earlier than 2011, it SHOULD NOT attempt to 242 validate incoming updates. It SHOULD defer validation until it 243 believes it is within reasonable time tolerance. 245 Servers should provide time service, such as [RFC5905], to client 246 routers. 248 9. Security Considerations 250 The major security considerations for the BGPsec protocol are 251 described in [I-D.ietf-sidr-bgpsec-protocol]. 253 10. IANA Considerations 255 This document has no IANA Considerations. 257 11. References 259 11.1. Normative References 261 [I-D.ietf-sidr-bgpsec-protocol] 262 Lepinski, M., "BGPSEC Protocol Specification", 263 draft-ietf-sidr-bgpsec-protocol-01 (work in progress), 264 October 2011. 266 [I-D.ietf-sidr-ghostbusters] 267 Bush, R., "The RPKI Ghostbusters Record", 268 draft-ietf-sidr-ghostbusters-16 (work in progress), 269 December 2011. 271 [I-D.lepinski-bgpsec-overview] 272 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 273 draft-lepinski-bgpsec-overview-00 (work in progress), 274 March 2011. 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, March 1997. 279 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 280 Secure Internet Routing", RFC 6480, February 2012. 282 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 283 Resource Certificate Repository Structure", RFC 6481, 284 February 2012. 286 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 287 Origin Authorizations (ROAs)", RFC 6482, February 2012. 289 11.2. Informative References 291 [I-D.ietf-sidr-pfx-validate] 292 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 293 Austein, "BGP Prefix Origin Validation", 294 draft-ietf-sidr-pfx-validate-03 (work in progress), 295 October 2011. 297 [I-D.rogaglia-sidr-bgpsec-rollover] 298 Gagliano, R., Patel, K., and B. Weis, "BGPSEC router key 299 roll-over as an alternative to beaconing", 300 draft-rogaglia-sidr-bgpsec-rollover-00 (work in progress), 301 March 2012. 303 [I-D.ymbk-bgpsec-rtr-rekeying] 304 Turner, S., Patel, K., and R. Bush, "Router Keying for 305 BGPsec", draft-ymbk-bgpsec-rtr-rekeying-00 (work in 306 progress), March 2012. 308 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 309 Protocol 4 (BGP-4)", RFC 4271, January 2006. 311 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 312 System Confederations for BGP", RFC 5065, August 2007. 314 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 315 Time Protocol Version 4: Protocol and Algorithms 316 Specification", RFC 5905, June 2010. 318 Author's Address 320 Randy Bush 321 Internet Initiative Japan 322 5147 Crystal Springs 323 Bainbridge Island, Washington 98110 324 US 326 Phone: +1 206 780 0431 x1 327 Email: randy@psg.com