idnits 2.17.1 draft-ietf-sidr-bgpsec-ops-04.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 13, 2012) is 4427 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-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-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 13, 2012 5 Expires: September 14, 2012 7 BGPsec Operational Considerations 8 draft-ietf-sidr-bgpsec-ops-04 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 14, 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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 On the other hand, an operator wanting to monitor router loading, 145 shifts in traffic, etc. will want to deploy incrementally while 146 watching those and similar effects. 148 As they are not signed, an eBGP listener SHOULD NOT strongly trust 149 unsigned markings such as communities received across a trust 150 boundary. 152 6. Considerations for Edge Sites 154 An edge site which does not provide transit and trusts its 155 upstream(s) SHOULD only originate a signed prefix announcement and 156 need not validate received announcements. 158 BGPsec protocol capability negotiation provides for a speaker signing 159 the data it sends but being unable to accept signed data. Thus a 160 smallish edge router may hold only its own signing key(s) and sign 161 it's announcement but not receive signed announcements and therefore 162 not need to deal with the majority of the RPKI. Thus such routers 163 CPU, RAM, and crypto needs are trivial and additional hardware should 164 not be needed. 166 As the vast majority (84%) of ASs are stubs, and they announce the 167 majority of prefixes, this allows for simpler and less expensive 168 incremental deployment. It may also mean that edge sites concerned 169 with routing security will be attracted to upstreams which support 170 BGPsec. 172 7. Routing Policy 174 Unlike origin validation based on the RPKI, BGPsec marks a received 175 announcement as Valid or Invalid, there is no NotFound state. How 176 this is used in routing is up to the operator's local policy. See 177 [I-D.ietf-sidr-pfx-validate]. 179 As BGPsec will be rolled out over years and does not allow for 180 intermediate non-signing edge routers, coverage will be spotty for a 181 long time. Hence a normal operator's policy SHOULD NOT be overly 182 strict, perhaps preferring valid announcements and giving very low 183 preference, but still using, invalid announcements. 185 A BGPsec speaker validates signed paths at the eBGP edge. 187 Local policy on the eBGP edge MAY convey the validation state of a 188 BGP signed path through normal local policy mechanisms, e.g. setting 189 a BGP community, or modifying a metric value such as local-preference 190 or MED. Some MAY choose to use the large Local-Pref hammer. Others 191 MAY choose to let AS-Path rule and set their internal metric, which 192 comes after AS-Path in the BGP decision process. 194 Because of possible RPKI version skew, an AS Path which does not 195 validate at router R0 might validate at R1. Therefore, signed paths 196 that are invalid and yet propagated (because they are chosen as best 197 path) SHOULD have their signatures kept intact and MUST be signed if 198 sent to external BGPsec speakers. 200 This implies that updates which a speaker judges to be invalid MAY be 201 propagated to iBGP peers. Therefore, unless local policy ensures 202 otherwise, a signed path learned via iBGP MAY be invalid. If needed, 203 the validation state should be signaled by normal local policy 204 mechanisms such as communities or metrics. 206 On the other hand, local policy on the eBGP edge might preclude iBGP 207 or eBGP announcement of signed AS Paths which are invalid. 209 A BGPsec speaker receiving a path SHOULD perform origin validation 210 per [I-D.ietf-sidr-pfx-validate]. 212 If it is known that a BGPsec neighbor is not a transparent route 213 server, and the router provides a knob to disallow a received pCount 214 (prepend count, zero for transparent route servers) of zero, that 215 knob SHOULD be applied. Routers should default to this knob 216 disallowing pCount 0. 218 To prevent exposure of the internals of BGP Confederations [RFC5065], 219 a BGPsec speaker which is a Member-AS of a Confederation MUST NOT 220 sign updates sent to another Member-AS of the same Confederation. 222 8. Notes 224 For protection from attacks replaying BGP data on the order of a day 225 or longer old, re-keying routers with new keys (previously) 226 provisioned in the RPKI is sufficient. For one procedure, see 227 [I-D.rogaglia-sidr-bgpsec-rollover] 229 Like the DNS, the global RPKI presents only a loosely consistent 230 view, depending on timing, updating, fetching, etc. Thus, one cache 231 or router may have different data about a particular prefix than 232 another cache or router. There is no 'fix' for this, it is the 233 nature of distributed data with distributed caches. 235 Operators who manage certificates SHOULD have RPKI Ghostbuster 236 Records (see [I-D.ietf-sidr-ghostbusters]), signed indirectly by End 237 Entity certificates, for those certificates on which others' routing 238 depends for certificate and/or ROA validation. 240 Operators should be aware of impending algorithm transitions, which 241 will be rare and slow-paced, see see 242 [I-D.ietf-sidr-algorithm-agility]. They should work with their 243 vendors to ensure support for new algorithms. 245 As a router must evaluate certificates and ROAs which are time 246 dependent, routers' clocks MUST be correct to a tolerance of 247 approximately an hour. 249 If a router has reason to believe its clock is seriously incorrect, 250 e.g. it has a time earlier than 2011, it SHOULD NOT attempt to 251 validate incoming updates. It SHOULD defer validation until it 252 believes it is within reasonable time tolerance. 254 Servers should provide time service, such as [RFC5905], to client 255 routers. 257 9. Security Considerations 259 The major security considerations for the BGPsec protocol are 260 described in [I-D.ietf-sidr-bgpsec-protocol]. 262 10. IANA Considerations 264 This document has no IANA Considerations. 266 11. References 268 11.1. Normative References 270 [I-D.ietf-sidr-bgpsec-protocol] 271 Lepinski, M., "BGPSEC Protocol Specification", 272 draft-ietf-sidr-bgpsec-protocol-01 (work in progress), 273 October 2011. 275 [I-D.ietf-sidr-ghostbusters] 276 Bush, R., "The RPKI Ghostbusters Record", 277 draft-ietf-sidr-ghostbusters-16 (work in progress), 278 December 2011. 280 [I-D.ietf-sidr-origin-ops] 281 Bush, R., "RPKI-Based Origin Validation Operation", 282 draft-ietf-sidr-origin-ops-15 (work in progress), 283 March 2012. 285 [I-D.lepinski-bgpsec-overview] 286 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 287 draft-lepinski-bgpsec-overview-00 (work in progress), 288 March 2011. 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 294 Secure Internet Routing", RFC 6480, February 2012. 296 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 297 Resource Certificate Repository Structure", RFC 6481, 298 February 2012. 300 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 301 Origin Authorizations (ROAs)", RFC 6482, February 2012. 303 11.2. Informative References 305 [I-D.ietf-sidr-algorithm-agility] 306 Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 307 Procedure for RPKI.", draft-ietf-sidr-algorithm-agility-05 308 (work in progress), January 2012. 310 [I-D.ietf-sidr-pfx-validate] 311 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 312 Austein, "BGP Prefix Origin Validation", 313 draft-ietf-sidr-pfx-validate-03 (work in progress), 314 October 2011. 316 [I-D.rogaglia-sidr-bgpsec-rollover] 317 Gagliano, R., Patel, K., and B. Weis, "BGPSEC router key 318 roll-over as an alternative to beaconing", 319 draft-rogaglia-sidr-bgpsec-rollover-00 (work in progress), 320 March 2012. 322 [I-D.ymbk-bgpsec-rtr-rekeying] 323 Turner, S., Patel, K., and R. Bush, "Router Keying for 324 BGPsec", draft-ymbk-bgpsec-rtr-rekeying-00 (work in 325 progress), March 2012. 327 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 328 Protocol 4 (BGP-4)", RFC 4271, January 2006. 330 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 331 System Confederations for BGP", RFC 5065, August 2007. 333 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 334 Time Protocol Version 4: Protocol and Algorithms 335 Specification", RFC 5905, June 2010. 337 Author's Address 339 Randy Bush 340 Internet Initiative Japan 341 5147 Crystal Springs 342 Bainbridge Island, Washington 98110 343 US 345 Phone: +1 206 780 0431 x1 346 Email: randy@psg.com