idnits 2.17.1 draft-ietf-sidr-bgpsec-overview-08.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 (June 22, 2016) is 2865 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR Working Group M. Lepinski 3 Internet Draft NCF 4 Intended status: Informational S. Turner 5 Expires: December 24, 2016 sn3rd 6 June 22, 2016 8 An Overview of BGPsec 9 draft-ietf-sidr-bgpsec-overview-08 11 Abstract 13 This document provides an overview of a security extension to the 14 Border Gateway Protocol (BGP) referred to as BGPsec. BGPsec improves 15 security for BGP routing. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute working 24 documents as Internet-Drafts. The list of current Internet-Drafts is 25 at http://datatracker.ietf.org/drafts/current. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 24, 2016. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. BGPsec Operation . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Negotiation of BGPsec . . . . . . . . . . . . . . . . . . . 4 55 3.2. Update signing and validation . . . . . . . . . . . . . . . 5 56 4. Design and Deployment Considerations . . . . . . . . . . . . . 7 57 4.1. Disclosure of topology information . . . . . . . . . . . . 7 58 4.2. BGPsec router assumptions . . . . . . . . . . . . . . . . . 7 59 4.3. BGPsec and consistency of externally visible data . . . . . 8 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 BGPsec (Border Gateway Protocol Security) is an extension to the 70 Border Gateway Protocol (BGP) that provides improved security for BGP 71 routing [RFC4271]. This document contains a brief overview of BGPsec 72 and its envisioned usage. 74 A more detailed discussion of BGPsec is provided in the following set 75 of documents: 77 * [RFC7132]: 79 A threat model describing the security context in which BGPsec 80 is intended to operate. 82 * [RFC7353]: 84 A set of requirements for BGP path security, which BGPsec is 85 intended to satisfy. 87 * [I-D.sidr-bgpsec-protocol]: 89 A standards track document specifying the BGPsec extension to 90 BGP. 92 * [I-D.sidr-as-migration]: 94 A standards track document describing how to implement an AS 95 Number migration while using BGPsec. 97 * [I-D.sidr-bgpsec-ops]: 99 An informational document describing operational considerations. 101 * [I-D.sidr-bgpsec-pki-profiles]: 103 A standards track document specifying a profile for X.509 104 certificates that bind keys used in BGPsec to Autonomous System 105 numbers, as well as associated Certificate Revocation Lists 106 (CRLs), and certificate requests. 108 * [I-D.sidr-bgpsec-algs] 110 A standards track document specifying suites of signature and 111 digest algorithms for use in BGPsec. 113 In addition to this document set, some readers might be interested in 114 [I-D.sriram-bgpsec-design-choices], an informational document 115 describing the choices that were made the by the design team prior to 116 the publication of the -00 version of draft-ietf-sidr-bgpsec- 117 protocol. Discussion of design choices made since the publication of 118 the -00 can be found in the archives of the SIDR working group 119 mailing list. 121 2. Background 123 The motivation for developing BGPsec is that BGP does not include 124 mechanisms that allow an Autonomous System (AS) to verify the 125 legitimacy and authenticity of BGP route advertisements (see for 126 example, [RFC4272]). 128 The Resource Public Key Infrastructure (RPKI), described in 129 [RFC6480], provides a first step towards addressing the validation of 130 BGP routing data. RPKI resource certificates are issued to the 131 holders of AS number and IP address resources, providing a binding 132 between these resources and cryptographic keys that can be used to 133 verify digital signatures. Additionally, the RPKI architecture 134 specifies a digitally signed object, a Route Origination 135 Authorization (ROA), that allows holders of IP address resources to 136 authorize specific ASes to originate routes (in BGP) to these 137 resources. Data extracted from a valid ROA can be used by a BGP 138 speaker to determine whether the origin AS asserted in a received 139 route has been authorized (by the Internet Number Resource holder) to 140 originate that route (see [RFC6483] and [RFC7115]). 142 By instituting a local policy that prefers routes with origins 143 validated using RPKI data (versus routes to the same prefix that 144 cannot be so validated) an AS can protect itself from configuration 145 errors by network operators and from certain mis-origination attacks. 146 However, use of RPKI data alone provides little or no protection 147 against a sophisticated attacker. Such an attacker could, for 148 example, conduct a route hijacking attack by appending an authorized 149 origin AS to an otherwise illegitimate AS path. (See [RFC7132] for a 150 detailed discussion of the BGPsec threat model.) 152 BGPsec extends the RPKI by adding an additional type of certificate, 153 referred to as a BGPsec Router Certificate, that binds an AS number 154 to a public signature verification key. The corresponding private 155 key is held by one or more BGP speakers within this AS. Private keys 156 corresponding to public keys in such certificates are used within 157 BGPsec to enable a BGP speaker to sign on behalf of its AS. The 158 certificates thus allow a relying party to verify that a BGPsec 159 signature was produced by a BGP speaker belonging to a given AS. The 160 goal of BGPsec is to use such signatures to protect the AS path data 161 in BGP update messages, so that each BGP speaker can assess the 162 validity of this data in update messages that it receives. 164 3. BGPsec Operation 166 The core of BGPsec is a new optional (non-transitive) attribute, 167 called BGPsec_Path. This attribute includes both AS Path data as well 168 as a sequence of digital signatures, one for each AS in the path. 169 (The use of this new attribute is formally specified in [I-D.sidr- 170 bgpsec-protocol].) A new signature is added to this sequence each 171 time an update message leaves an AS. The signature is constructed so 172 that any tampering with the AS path data or Network Layer 173 Reachability Information (NLRI) in the BGPsec update message can be 174 detected by the recipient of the message. 176 3.1. Negotiation of BGPsec 178 The use of BGPsec is negotiated using BGP capability advertisements 179 [RFC5492]. Upon opening a BGP session with a peer, BGP speakers who 180 support (and wish to use) BGPsec include a newly-defined capability 181 in the OPEN message [I-D.sidr-bgpsec-protocol]. 183 The use of BGPsec is negotiated separately for each address family. 184 This means that a BGP speaker could, for example, elect to use BGPsec 185 for IPv6, but not for IPv4 (or vice versa) routes. Additionally, the 186 use of BGPsec is negotiated separately in the send and receive 187 directions. This means that a BGP speaker could, for example, 188 indicate support for sending BGPsec update messages but require that 189 messages it receives be traditional (non-BGPsec) update message. (To 190 see why such a feature is useful, see Section 4.2.) 192 If the use of BGPsec is negotiated in a BGP session (in a given 193 direction, for a given address family) then both BGPsec update 194 messages (ones that contain the BGPsec_Path_Signature attribute) and 195 traditional BGP update messages (that do not contain this attribute) 196 can be sent within the session. 198 If a BGPsec-capable BGP speaker finds that its peer does not support 199 receiving BGPsec update messages, then the BGP speaker must remove 200 the BGPsec_Path attribute from any update messages it sends to this 201 peer. 203 3.2. Update signing and validation 205 When a BGP speaker originates a BGPsec update message, it creates a 206 BGPsec_Path attribute containing a single signature. The signature 207 protects the Network Layer Reachability Information (NLRI), the AS 208 number of the originating AS, and the AS number of the peer AS to 209 which the update message is being sent. Note that the NLRI in a 210 BGPsec update message is restricted to contain only a single prefix. 212 When a BGP speaker receives a BGPsec update message and wishes to 213 propagate the route advertisement contained in the update to an 214 external peer, it adds a new signature to the BGPsec_Path attribute. 215 This signature protects everything protected by the previous 216 signature, plus the AS number of the new peer to which the update 217 message is being sent. 219 Each BGP speaker also includes a reference, called a Subject Key 220 Identifier (SKI). The SKI identifies the BGPsec Router Certificate 221 of the BGP speaker signing the BGPsec_Path attribute. The SKI is 222 used by a recipient to select the public key (and associated router 223 certificate data) needed to validate the signature. 225 As an example, consider the following case in which an advertisement 226 for 192.0.2/24 is originated by AS 1, which sends the route to AS 2, 227 which sends it to AS 3, which sends it to AS 4. When AS 4 receives a 228 BGPsec update message for this route, it will contain the following 229 data: 231 * NLRI: 192.0.2/24 232 * AS path data: 3 2 1 233 * BGPsec_Path contains 3 signatures : 234 o Signature from AS 1 protecting 235 192.0.2/24, AS 1 and AS 2 236 o Signature from AS 2 protecting 237 Everything AS 1's signature protected, and AS 3 238 o Signature from AS 3 protecting 239 Everything AS 2's signature protected, and AS 4 241 When a BGPsec update message is received by a BGPsec speaker, the 242 BGPsec speaker can validate the message as follows. For each 243 signature, the BGP speaker first determines if there is a valid RPKI 244 Router certificate matching the SKI and containing the appropriate AS 245 number. (This would typically be done by looking up the SKI in a 246 cache of data extracted from valid RPKI objects. A cache allows 247 certificate validation to be handled via an asynchronous process, 248 which might execute on another device.) 250 The BGPsec speaker then verifies the signature using the public key 251 from this BGPsec router certificate. If each of the signatures can be 252 verified in this fashion, the BGPsec speaker is assured that the 253 update message it received was propagated via the AS path specified 254 in the update message. 256 In the above example, upon receiving the BGPsec update message, a BGP 257 speaker for AS 4 would do the following. First, it would look at the 258 SKI for the first signature and see if this corresponds to a valid 259 BGPsec Router certificate for AS 1. Next, it would verify the first 260 signature using the key found in this valid certificate. Finally, it 261 would repeat this process for the second and third signatures, 262 checking to see that there are valid BGPsec router certificates for 263 AS 2 and AS 3 (respectively) and that the signatures can be verified 264 with the keys found in these certificates. Note that the BGPsec 265 speaker for AS 4 should additionally perform origin validation as per 266 RFC 6483 [RFC6483]. However, such origin validation is independent of 267 BGPsec. 269 The deployment model for BGPsec requires that all ASs in a BGPsec 270 protected path must be BGPsec speakers. It does not permit BGPsec 271 protection of an update that propagates through ASs that do not 272 support BGPsec. In particular, it does not permit what is called 273 "partial path signing", in which a BGPsec AS attaches a BGPsec_Path 274 attribute to an unprotected update that was received from a 275 downstream neighbor. 277 Partial path signing might be viewed as supplying information about a 278 portion of a path that could be used in making better routing 279 decisions, preferring a partially protected route. However, partial 280 path signing implies that the entire AS path is not rigorously 281 protected. Rigorous AS path protection is a key requirement of 282 BGPsec [RFC7353]. Partial path signing also introduces the following 283 attack vulnerability: If a BGPsec speaker can attach a BGPsec_Path 284 attribute to an unprotected update, and if BGPsec protected updates 285 would be preferred to unprotected updates, then a BGPsec speaker can 286 manufacture any unprotected update it wants and attach a BGPsec_Path 287 attribute to it, and thereby increase the chance that its 288 manufactured update will be preferred. Partial path signing then 289 becomes a privilege elevation attack vector, that could be employed 290 by any BGPsec AS at any point. 292 The need to avoid introducing that vulnerability forced the stringent 293 deployment model. 295 4. Design and Deployment Considerations 297 In this section we provide a brief overview of several additional 298 topics that commonly arise in the discussion of BGPsec. 300 4.1. Disclosure of topology information 302 A key requirement in the design of BGPsec was that it not disclose 303 any new information about BGP peering topology. Since many ISPs feel 304 peering topology data is proprietary, further disclosure of it would 305 inhibit BGPsec adoption. 307 In particular, the topology information that can be inferred from 308 BGPsec update messages is exactly the same as that which can be 309 inferred from equivalent (non-BGPsec) BGP update messages. 311 4.2. BGPsec router assumptions 313 In order to achieve its security goals, BGPsec assumes additional 314 capabilities in routers. In particular, BGPsec requires adding 315 digital signatures to BGP update messages, which will significantly 316 increase the size of these messages. Therefore, an AS that wishes to 317 receive BGPsec update messages will require additional memory in its 318 routers to store (e.g., in ADJ RIBs) the data conveyed in these 319 larger update messages. Additionally, the design of BGPsec assumes 320 that an AS that elects to receive BGPsec update messages will do some 321 cryptographic signature verification at its edge router. This 322 verification may require additional capability in these edge routers. 324 Additionally, BGPsec requires that all BGPsec speakers support 4-byte 325 AS Numbers [RFC6793]. This is because the co-existence strategy for 326 4-byte AS numbers and legacy 2-byte AS speakers that gives special 327 meaning to AS 23456 is incompatible with the security properties that 328 BGPsec seeks to provide. 330 For this initial version of BGPsec, optimizations to minimize the 331 size of BGPsec updates or the processing required in edge routers 332 have not been considered. Such optimizations may be considered in the 333 future. 335 Note also that the design of BGPsec allows an AS to send BGPsec 336 update messages (thus obtaining protection for routes it originates) 337 without receiving BGPsec update messages. An AS that sends, but does 338 not receive, BGPsec update messages, will require much less 339 capability in its edge routers to deploy BGPsec. In particular, a 340 router that only sends BGPsec update messages does not need 341 additional memory to store larger updates and requires only minimal 342 cryptographic capability (as generating one signature per outgoing 343 update requires less computation than verifying multiple signatures 344 on each incoming update message). See [I-D.sidr-bgpsec-ops] for 345 further discussion related to Edge ASes that do not provide transit. 347 4.3. BGPsec and consistency of externally visible data 349 Finally note that, by design, BGPsec prevents parties that propagate 350 route advertisements from including inconsistent or erroneous 351 information within the AS-Path (without detection). In particular, 352 this means that any scenarios in which a BGP speaker constructs such 353 an inconsistent or erroneous AS Path attribute will break when BGPsec 354 is used. 356 For example, when BGPsec is not used, it is possible for a single 357 autonomous system to have one peering session where it identifies 358 itself as AS 111 and a second peering session where it identifies 359 itself as AS 222. In such a case, it might receive route 360 advertisements from the first peering session (as AS 111) and then 361 add AS 222 (but not AS 111) to the AS-Path and propagate them within 362 the second peering session. 364 Such behavior may very well be innocent and performed with the 365 consent of the legitimate holder of both AS 111 and 222. However, it 366 is indistinguishable from the following man-in-the-middle attack 367 performed by a malicious AS 222. First, the malicious AS 222 368 impersonates AS 111 in the first peering session (essentially 369 stealing a route advertisement intended for AS 111). The malicious 370 AS 222 then inserts itself into the AS path and propagates the update 371 to its peers. 373 Therefore, when BGPsec is used, such an autonomous system would 374 either need to assert a consistent AS number in all external peering 375 sessions, or else it would need to add both AS 111 and AS 222 to the 376 AS-Path (along with appropriate signatures) for route advertisements 377 that it receives from the first peering session and propagates within 378 the second peering session. See [I-D.sidr-as-migration] for a 379 detailed discussion of how to reasonably manage AS number migrations 380 while using BGPsec. 382 5. Security Considerations 384 This document provides an overview of BGPsec; it does not define the 385 BGPsec extension to BGP. The BGPsec extension is defined in [I- 386 D.sidr-bgpsec-protocol]. The threat model for the BGPsec is 387 described in [RFC7132]. 389 6. IANA Considerations 391 None. 393 7. References 395 7.1. Normative References 397 [RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway 398 Protocol 4 (BGP-4)", RFC 4271, January 2006. 400 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 401 Numbers", RFC 6793, December 2012. 403 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 404 with BGP-4", RFC 5492, February 2009. 406 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 407 Secure Internet Routing", February 2012. 409 [RFC6483] Huston, G., and G. Michaelson, "Validation of Route 410 Origination using the Resource Certificate PKI and ROAs", February 411 2012. 413 [RFC7132] Kent, S., and A. Chi, "Threat Model for BGP Path Security", 414 RFC 7132, February 2014. 416 [RFC7115] Bush, R., "RPKI-Based Origin Validation Operation", RFC 417 7115, January 2014. 419 [I-D.sidr-bgpsec-protocol] Lepinski, M., Ed., "BPSEC Protocol 420 Specification", draft-ietf-sidr-bgpsec-protocol, work-in-progress. 422 [I-D.sidr-bgpsec-ops] Bush, R., "BGPsec Operational Considerations", 423 draft-ietf-sidr-bgpsec-ops, work-in-progress. 425 [I-D.sidr-bgpsec-algs] Turner, S., "BGPsec Algorithms, Key Formats, & 426 Signature Formats", draft-ietf-sidr-bgpsec-algs, work-in-progress. 428 [I-D.sidr-bgpsec-pki-profiles] Reynolds, M., Turner, S., and S. Kent, 429 "A Profile for BGPsec Router Certificates, Certificate Revocation 430 Lists, and Certification Requests", 431 draft-ietf-sidr-bgpsec-pki-profiles, work-in-progress. 433 [I-D.sidr-as-migration] George, W. and S. Murphy, "BGPsec 434 Considerations for AS Migration", draft-ietf-sidr-as-migration, 435 work-in-progress. 437 7.2. Informative References 439 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 440 4272, January 2006 442 [I-D.sriram-bgpsec-design-choices] Sriram, K., "BGPsec Design Choices 443 and Summary of Supporting Discussions", 444 draft-sriram-bgpsec-design-choices, work-in-progress. 446 [RFC7353] Bellovin, S., R. Bush, and D. Ward, "Security Requirements 447 for BGP Path Validation", RFC 7353, August 2014. 449 Authors' Addresses 451 Matt Lepinski 452 New College of Florida 453 5800 Bay Shore Road 454 Sarasota, FL 34243 455 USA 457 Email: mlepinski@ncf.edu 459 Sean Turner 460 sn3rd 462 Email: sean@sn3rd.com