idnits 2.17.1 draft-ymbk-bgpsec-ops-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: This implies that AS Paths with non-validated signatures MAY be propagated to iBGP peers. Therefore, unless local policy ensures otherwise, a signed path learned via iBGP MAY NOT have been validated. If needed, the validation state SHOULD be signaled by normal policy mechanisms such as communities or metrics. -- The document date (March 15, 2011) is 4784 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) == Missing Reference: 'BGPsec' is mentioned on line 298, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-sidr-ghostbusters-02 == Outdated reference: A later version (-12) exists of draft-ietf-sidr-roa-format-10 ** Downref: Normative reference to an Informational draft: draft-lepinski-bgpsec-overview (ref. 'I-D.lepinski-bgpsec-overview') == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-12 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-ltamgmt-00 == Outdated reference: A later version (-09) exists of draft-ietf-sidr-repos-struct-07 == Outdated reference: A later version (-02) exists of draft-ymbk-rfd-usable-00 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). 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 15, 2011 5 Expires: September 16, 2011 7 BGPsec Operational Considerations 8 draft-ymbk-bgpsec-ops-01 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 RFC 2119 [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. This document may not be modified, 27 and derivative works of it may not be created, and it may not be 28 published except as an Internet-Draft. 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 September 16, 2011. 42 Copyright Notice 44 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . . 3 62 4. AS/Router Certificates . . . . . . . . . . . . . . . . . . . . 4 63 5. Within a Network . . . . . . . . . . . . . . . . . . . . . . . 4 64 6. Considerations for Edge Sites . . . . . . . . . . . . . . . . . 5 65 7. Beaconing Considerations . . . . . . . . . . . . . . . . . . . 5 66 8. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . 6 67 9. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 71 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 13.1. Normative References . . . . . . . . . . . . . . . . . . . 8 73 13.2. Informative References . . . . . . . . . . . . . . . . . . 8 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 BGPsec is a new protocol with many operational considerations. It is 79 expected to be deployed incrementally over a number of years. As 80 core BGPsec-capable routers may require large memory and crypto 81 assist, it is thought that origin validation based on the RPKI will 82 occur over the next two to five years and that BGPsec will start to 83 deploy late in that window. 85 BGPsec relies on widespread propagation of the Resource Public Key 86 Infrastructure (RPKI) [I-D.ietf-sidr-arch]. How the RPKI is 87 distributed and maintained globally and within an operator's 88 infrastructure may be different for BGPsec than for origin 89 validation. 91 BGPsec need be spoken only by a AS's eBGP speaking, AKA border, 92 routers, and is designed so that it can be used to protect 93 announcements which are originated by small edge routers, and this 94 has special operational considerations. 96 Different prefixes have different timing and replay protection 97 considerations. 99 2. Suggested Reading 101 It is assumed that the reader understands BGP, [RFC4271], BGPsec, 102 [I-D.lepinski-bgpsec-overview], the RPKI, see [I-D.ietf-sidr-arch], 103 the RPKI Repository Structure, see [I-D.ietf-sidr-repos-struct], and 104 ROAs, see [I-D.ietf-sidr-roa-format]. 106 3. RPKI Distribution and Maintenance 108 The RPKI is a distributed database containing certificates, CRLs, 109 manifests, ROAs, and Ghostbuster Records as described in 110 [I-D.ietf-sidr-repos-struct]. Policies and considerations for RPKI 111 object generation and maintenance are discussed elsewhere. 113 A local valid cache containing all RPKI data may be gathered from the 114 global distributed database using the rsync protocol and a validation 115 tool such as rcynic. 117 Validated caches may also be created and maintained from other 118 validated caches. Network operators SHOULD take maximum advantage of 119 this feature to minimize load on the global distributed RPKI 120 database. 122 As RPKI-based origin validation relies on the availability of RPKI 123 data, operators SHOULD locate caches close to routers that require 124 these data and services. A router can peer with one or more nearby 125 caches. 127 For redundancy, a router SHOULD peer with more than one cache at the 128 same time. Peering with two or more, at least one local and others 129 remote, is recommended. 131 If an operator trusts upstreams to carry their traffic, they SHOULD 132 also trust the RPKI data those upstreams cache, and SHOULD peer with 133 those caches. Note that this places an obligation on those upstreams 134 to maintain fresh and reliable caches. 136 A transit provider or a network with peers SHOULD validate NLRI in 137 announcements made by upstreams, downstreams, and peers. They still 138 SHOULD trust the caches provided by their upstreams. 140 An environment where private address space is announced in eBGP the 141 operator MAY have private RPKI objects which cover these private 142 spaces. This will require a trust anchor created and owned by that 143 environment, see [I-D.ietf-sidr-ltamgmt]. 145 4. AS/Router Certificates 147 A site/operator MAY use a single certificate/key in all their 148 routers, one certificate/key per router, or any granularity in 149 between. 151 A large operator, concerned that a compromise of one router's key 152 would make many routers vulnerable, MAY accept a more complex 153 certificate/key distribution burden to reduce this exposure. 155 On the other extreme, an edge site with one or two routers MAY use a 156 single certificate/key. 158 Routers MAY be capable of generating their own keys and having their 159 certificates signed and published in the RPKI by their NOC. This 160 would mean that a router's private key need never leave the router. 162 5. Within a Network 164 BGPsec is spoken by edge routers in a network, those which border 165 other networks/ASs. 167 In a fully BGPsec enabled AS, Route Reflectors MUST have BGPsec 168 enabled if and only if there are eBGP speakers in their client cone. 170 A BGPsec capable router MAY use the data it receives to influence 171 local policy within its network, see Section 8. In deployment this 172 policy should fit into the AS's existing policy, preferences, etc. 173 This allows a network to incrementally deploy BGPsec capable border 174 routers. 176 eBGP speakers which face more critical peers or up/downstreams would 177 be candidates for the earliest deployment. Both securing one's own 178 announcements and validating received announcements should be 179 considered in partial deployment. 181 An eBGP listener MUST NOT trust non-BGPsec markings such as 182 communities received across a trust boundary. 184 6. Considerations for Edge Sites 186 An edge site which does not provide transit and trusts its 187 upstream(s) SHOULD only originate a signed prefix announcement and 188 need not validate received announcements. 190 BGPsec protocol capability negotiation provides for a speaker signing 191 the data it sends but being unable to accept signed data. Thus a 192 smallish edge router may hold only its own signing key(s) and sign 193 it's announcement but not receive signed announcements and therefore 194 not need to deal with the majority of the RPKI. 196 As the vast majority (84%) of ASs are stubs, and they announce the 197 majority of prefixes, this allows for simpler and cheaper early 198 incremental deployment. It may also mean that edge sites concerned 199 with routing security will be attracted to upstreams which support 200 BGPsec. 202 7. Beaconing Considerations 204 The BGPsec protocol attempts to reduce exposure to replay attacks by 205 allowing the route originator to sign an announcement with a validity 206 period and re-announce well within that period. 208 This re-announcement is termed 'beaconing'. All timing values are, 209 of course, jittered. 211 It is only the originator of an NLRI which signs the announcement 212 with a validity period. 214 To reduce vulnerability to a lost beacon announcement, a router 215 SHOULD beacon at a rate somewhat greater than half the signature 216 validity period it uses. 218 As beaconing places a load on the entire global routing system, 219 careful thought MUST be given to any need to beacon frequently. This 220 would be based on a conservative estimation of the vulnerability to a 221 replay attack. 223 Beacon timing and signature validity periods SHOULD be as follows: 225 The Exemplary Citizen: Prefix originators who are not overly 226 concerned about replay attacks might announce with a signature 227 validity of multiple weeks and beacon one third of the validity 228 period. 230 Normal Prefix: Most prefixes SHOULD announce with a signature 231 validity of a week and beacon every three days. 233 Critical Prefix: Of course, we all think what we do is critical. 234 But prefixes of top level DNS servers, and RPKI publication points 235 are actually critical to large swaths of the Internet and are 236 therefore tempting targets for replay attacks. It is suggested 237 that the beaconing of these prefixes SHOULD be two to four hours, 238 with a signature validity of six to twelve hours. 240 Note that this may incur route flap damping (RFD) with current 241 default but deprecated RFD parameters, see [I-D.ymbk-rfd-usable]. 243 8. Routing Policy 245 Unlike origin validation based on the RPKI, BGPsec marks a received 246 announcement as Valid or Invalid, there is no NotFound state. How 247 this is used in routing is up to the operator's local policy. See 248 [I-D.pmohapat-sidr-pfx-validate]. 250 As BGPsec will be rolled out over years and does not allow for 251 intermediate non-signing edge routers, coverage will be spotty for a 252 long time. Hence a normal operator's policy SHOULD NOT be overly 253 strict, perhaps preferring valid announcements and giving very low 254 preference, but still using, invalid announcements. 256 Local policy on the eBGP edge MAY convey the validation status of a 257 BGP signed path through various pre-existing mechanisms, e.g. setting 258 a BGP community, or modifying a metric value such as local-preference 259 or MED. Some MAY choose to use the large Local-Pref hammer. Others 260 MAY choose to let AS-Path rule and set their internal metric, which 261 comes after AS-Path in the BGP decision process. 263 A BGPsec speaker validates signed paths at the eBGP edge. 265 Because of possible RPKI version skew, an AS Path which does not 266 validate at router R0 might validate at R1. Therefore, signed paths 267 that can not be validated SHOULD have their signatures kept intact 268 and should be signed when sent to external BGPsec speakers. 270 This implies that AS Paths with non-validated signatures MAY be 271 propagated to iBGP peers. Therefore, unless local policy ensures 272 otherwise, a signed path learned via iBGP MAY NOT have been 273 validated. If needed, the validation state SHOULD be signaled by 274 normal policy mechanisms such as communities or metrics. 276 On the other hand, local policy on the eBGP edge might preclude iBGP 277 or eBGP announcement of signed AS Paths which are not validated. 279 If a BGPsec speaker receives an unsigned path, it SHOULD perform 280 origin validation per [I-D.pmohapat-sidr-pfx-validate]. 282 9. Notes 284 Like the DNS, the global RPKI presents only a loosely consistent 285 view, depending on timing, updating, fetching, etc. Thus, one cache 286 or router may have different data about a particular prefix than 287 another cache or router. There is no 'fix' for this, it is the 288 nature of distributed data with distributed caches. 290 Operators which manage certificates SHOULD have RPKI Ghostbuster 291 Records (see [I-D.ietf-sidr-ghostbusters]), signed indirectly by End 292 Entity certificates, for those certificates on which others' routing 293 depends for certificate and/or ROA validation. 295 10. Security Considerations 297 BGPsec is all about security, routing security. The major security 298 considerations for the protocol are described in [BGPsec]. 300 11. IANA Considerations 302 This document has no IANA Considerations. 304 12. Acknowledgments 306 The author wishes to thank the entire BGPsec foundation team. 308 13. References 310 13.1. Normative References 312 [I-D.ietf-sidr-ghostbusters] 313 Bush, R., "The RPKI Ghostbusters Record", 314 draft-ietf-sidr-ghostbusters-02 (work in progress), 315 March 2011. 317 [I-D.ietf-sidr-roa-format] 318 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 319 Origin Authorizations (ROAs)", 320 draft-ietf-sidr-roa-format-10 (work in progress), 321 February 2011. 323 [I-D.lepinski-bgpsec-overview] 324 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 325 draft-lepinski-bgpsec-overview-00 (work in progress), 326 March 2011. 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, March 1997. 331 13.2. Informative References 333 [I-D.ietf-sidr-arch] 334 Lepinski, M. and S. Kent, "An Infrastructure to Support 335 Secure Internet Routing", draft-ietf-sidr-arch-12 (work in 336 progress), February 2011. 338 [I-D.ietf-sidr-ltamgmt] 339 Kent, S. and M. Reynolds, "Local Trust Anchor Management 340 for the Resource Public Key Infrastructure", 341 draft-ietf-sidr-ltamgmt-00 (work in progress), 342 November 2010. 344 [I-D.ietf-sidr-repos-struct] 345 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 346 Resource Certificate Repository Structure", 347 draft-ietf-sidr-repos-struct-07 (work in progress), 348 February 2011. 350 [I-D.pmohapat-sidr-pfx-validate] 351 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 352 Austein, "BGP Prefix Origin Validation", 353 draft-pmohapat-sidr-pfx-validate-07 (work in progress), 354 April 2010. 356 [I-D.ymbk-rfd-usable] 357 Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O. 358 Maennel, "Making Route Flap Damping Usable", 359 draft-ymbk-rfd-usable-00 (work in progress), March 2011. 361 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 362 Protocol 4 (BGP-4)", RFC 4271, January 2006. 364 Author's Address 366 Randy Bush 367 Internet Initiative Japan 368 5147 Crystal Springs 369 Bainbridge Island, Washington 98110 370 US 372 Phone: +1 206 780 0431 x1 373 Email: randy@psg.com