idnits 2.17.1 draft-ietf-sidr-bgpsec-overview-06.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 15, 2015) is 3388 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 4271' is mentioned on line 76, but not defined == Missing Reference: 'I-D.turner-sidr-bgpsec-pki-profiles' is mentioned on line 106, but not defined == Missing Reference: 'I-D.turner-sidr-bgpsec-algs' is mentioned on line 113, but not defined == Missing Reference: 'RFC 4272' is mentioned on line 131, but not defined == Missing Reference: 'RFC 5492' is mentioned on line 183, but not defined == Missing Reference: 'I-D.sidr-bgpsec-threats' is mentioned on line 373, but not defined == Unused Reference: 'RFC4271' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'I-D.sidr-bgpsec-algs' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'I-D.sidr-bgpsec-pki-profiles' is defined on line 412, but no explicit reference was found in the text == Unused Reference: 'RFC4272' is defined on line 423, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) -- No information found for draft-sidr-bgpsec-pki-profiles - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Lepinski 3 Internet Draft BBN Technologies 4 Intended status: Informational S. Turner 5 Expires: July 15, 2015 IECA 6 January 15, 2015 8 An Overview of BGPsec 9 draft-ietf-sidr-bgpsec-overview-06 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), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 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 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on July 15, 2015. 40 Copyright Notice 42 Copyright (c) 2015 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...................................................2 58 2. Background.....................................................3 59 3. BGPsec Operation...............................................4 60 3.1. Negotiation of BGPsec.....................................4 61 3.2. Update signing and validation.............................5 62 4. Design and Deployment Considerations...........................6 63 4.1. Disclosure of topology information........................7 64 4.2. BGPsec router assumptions.................................7 65 4.3. BGPsec and consistency of externally visible data.........8 66 5. Security Considerations........................................8 67 6. IANA Considerations............................................8 68 7. References.....................................................9 69 7.1. Normative References......................................9 70 7.2. Informative References....................................9 72 1. Introduction 74 BGPsec (Border Gateway Protocol Security) is an extension to the 75 Border Gateway Protocol (BGP) that provides improved security for BGP 76 routing [RFC 4271]. This document contains a brief overview of BGPsec 77 and its envisioned usage. 79 A more detailed discussion of BGPsec is provided in the following set 80 of documents: 82 . [RFC7132]: 84 A threat model describing the security context in which BGPsec 85 is intended to operate. 87 . [RFC7353]: 89 A set of requirements for BGP path security, which BGPsec is 90 intended to satisfy. 92 . [I-D.sidr-bgpsec-protocol]: 94 A standards track document specifying the BGPsec extension to 95 BGP. 97 . [I-D.sidr-as-migration]: 99 A standards track document describing how to implement an AS 100 Number migration while using BGPsec. 102 . [I-D.sidr-bgpsec-ops]: 104 An informational document describing operational considerations. 106 . [I-D.turner-sidr-bgpsec-pki-profiles]: 108 A standards track document specifying a profile for X.509 109 certificates that bind keys used in BGPsec to Autonomous System 110 numbers, as well as associated Certificate Revocation Lists 111 (CRLs), and certificate requests. 113 . [I-D.turner-sidr-bgpsec-algs] 115 A standards track document specifying suites of signature and 116 digest algorithms for use in BGPsec. 118 In addition to this document set, some readers might be interested in 119 [I-D.sriram-bgpsec-design-choices], an informational document 120 describing the choices that were made the by the author team prior to 121 the publication of the -00 version of draft-ietf-sidr-bgpsec- 122 protocol. Discussion of design choices made since the publication of 123 the -00 can be found in the archives of the SIDR working group 124 mailing list. 126 2. Background 128 The motivation for developing BGPsec is that BGP does not include 129 mechanisms that allow an Autonomous System (AS) to verify the 130 legitimacy and authenticity of BGP route advertisements (see for 131 example, [RFC 4272]). 133 The Resource Public Key Infrastructure (RPKI), described in 134 [RFC6480], provides a first step towards addressing the validation of 135 BGP routing data. RPKI resource certificates are issued to the 136 holders of AS number and IP address resources, providing a binding 137 between these resources and cryptographic keys that can be used to 138 verify digital signatures. Additionally, the RPKI architecture 139 specifies a digitally signed object, a Route Origination 140 Authorization (ROA), that allows holders of IP address resources to 141 authorize specific ASes to originate routes (in BGP) to these 142 resources. Data extracted from valid ROAs can be used by BGP speakers 143 to determine whether a received route was actually originated by an 144 AS authorized to originate that route (see [RFC6483] and [RFC7115]). 146 By instituting a local policy that prefers routes with origins 147 validated using RPKI data (versus routes to the same prefix that 148 cannot be so validated) an AS can protect itself from certain mis- 149 origination attacks. However, use of RPKI data alone provides little 150 or no protection against a sophisticated attacker. Such an attacker 151 could, for example, conduct a route hijacking attack by appending an 152 authorized origin AS to an otherwise illegitimate AS path. (See [I- 153 D.sidr-bgpsec-threats] for a detailed discussion of the BGPsec threat 154 model.) 156 BGPsec extends the RPKI by adding an additional type of certificate, 157 referred to as a BGPsec router certificate, that binds an AS number 158 to a public signature verification key, the corresponding private key 159 of which is held by one or more BGP speakers within this AS. Private 160 keys corresponding to public keys in such certificates can then be 161 used within BGPsec to enable BGP speakers to sign on behalf of their 162 AS. The certificates thus allow a relying party to verify that a 163 BGPsec signature was produced by a BGP speaker belonging to a given 164 AS. The goal of BGPsec is to use such signatures to protect the AS 165 path data in BGP update messages so that a BGP speaker can assess the 166 validity of the AS path data in update messages that it receives. 168 3. BGPsec Operation 170 The core of BGPsec is a new optional (non-transitive) attribute, 171 called BGPsec_Path. This attribute includes both AS Path data as well 172 as a sequence of digital signatures, one for each AS in the path. 173 (The use of this new attribute is formally specified in [I-D.sidr- 174 bgpsec-protocol].) A new signature is added to this sequence each 175 time an update message leaves an AS. The signature is constructed so 176 that any tampering with the AS path data or Network Layer 177 Reachability Information (NLRI) in the BGPsec update message can be 178 detected by the recipient of the message. 180 3.1. Negotiation of BGPsec 182 The use of BGPsec is negotiated using BGP capability advertisements 183 [RFC 5492]. Upon opening a BGP session with a peer, BGP speakers who 184 support (and wish to use) BGPsec include a newly-defined capability 185 in the OPEN message. 187 The use of BGPsec is negotiated separately for each address family. 188 This means that a BGP speaker could, for example, elect to use BGPsec 189 for IPv6, but not for IPv4 (or vice versa). Additionally, the use of 190 BGPsec is negotiated separately in the send and receive directions. 192 This means that a BGP speaker could, for example, indicate support 193 for sending BGPsec update messages but require that messages it 194 receives be traditional (non-BGPsec) update message. (To see why such 195 a feature might be useful, see Section 4.2.) 197 If the use of BGPsec is negotiated in a BGP session (in a given 198 direction, for a given address family) then both BGPsec update 199 messages (ones that contain the BGPsec_Path_Signature attribute) and 200 traditional BGP update messages (that do not contain this attribute) 201 can be sent within the session. 203 If a BGPsec-capable BGP speaker finds that its peer does not support 204 receiving BGPsec update messages, then the BGP speaker must remove 205 existing BGPsec_Path attribute from any update messages it sends to 206 this peer. 208 3.2. Update signing and validation 210 When a BGP speaker originates a BGPsec update message, it creates a 211 BGPsec_Path attribute containing a single signature. The signature 212 protects the Network Layer Reachability Information (NLRI), the AS 213 number of the originating AS, and the AS number of the peer AS to 214 whom the update message is being sent. Note that the NLRI in a BGPsec 215 update message is restricted to contain only a single prefix. 217 When a BGP speaker receives a BGPsec update message and wishes to 218 propagate the route advertisement contained in the update to an 219 external peer, it adds a new signature to the BGPsec_Path attribute. 220 This signature protects everything protected by the previous 221 signature, plus the AS number of the new peer to whom the update 222 message is being sent. 224 Each BGP speaker also adds a reference, called a Subject Key 225 Identifier (SKI), to its BGPsec Router certificate. The SKI is used 226 by a recipient to select the public key (and associated router 227 certificate data) needed for validation. 229 As an example, consider the following case in which an advertisement 230 for 192.0.2/24 is originated by AS 1, which sends the route to AS 2, 231 which sends it to AS 3, which sends it to AS 4. When AS 4 receives a 232 BGPsec update message for this route, it will contain the following 233 data: 235 . NLRI : 192.0.2/24 237 . AS path data: 3 2 1 239 . BGPsec_Path contains 3 signatures : 241 o Signature from AS 1 protecting 243 192.0.2/24, AS 1 and AS 2 245 o Signature from AS 2 protecting 247 Everything AS 1's signature protected, and AS 3 249 o Signature from AS 3 protecting 251 Everything AS 2's signature protected, and AS 4 253 When a BGPsec update message is received by a BGP speaker, the BGP 254 speaker can validate the message as follows. For each signature, the 255 BGP speaker first needs to determine if there is a valid RPKI Router 256 certificate matching the SKI and containing the appropriate AS 257 number. (This would typically be done by looking up the SKI in a 258 cache of data extracted from valid RPKI objects. A cache allows 259 certificate validation to be handled via an asynchronous process, 260 which might execute on another device.) 262 The BGP speaker then verifies the signature using the public key from 263 this BGPsec router certificate. If all the signatures can be verified 264 in this fashion, the BGP speaker is assured that the update message 265 it received actually came via the AS path specified in the update 266 message. 268 In the above example, upon receiving the BGPsec update message, a BGP 269 speaker for AS 4 would do the following. First, it would look at the 270 SKI for the first signature and see if this corresponds to a valid 271 BGPsec Router certificate for AS 1. Next, it would verify the first 272 signature using the key found in this valid certificate. Finally, it 273 would repeat this process for the second and third signatures, 274 checking to see that there are valid BGPsec router certificates for 275 AS 2 and AS 3 (respectively) and that the signatures can be verified 276 with the keys found in these certificates. Note that the BGPsec 277 speaker for AS 4 should additionally perform origin validation as per 278 RFC 6483 [RFC6483]. However, such origin validation is independent of 279 BGPsec. 281 4. Design and Deployment Considerations 283 In this section we provide a brief overview of several additional topics that 284 commonly arise in the discussion of BGPsec. 286 4.1. Disclosure of topology information 288 A key requirement in the design of BGPsec was that BGPsec not 289 disclose any new information about BGP peering topology. Since many 290 ISPs feel peering topology data is proprietary, further disclosure of 291 it would inhibit BGPsec adoption. 293 In particular, the topology information that can be inferred from 294 BGPsec update messages is exactly the same as that which can be 295 inferred from equivalent (non-BGPsec) BGP update messages. 297 4.2. BGPsec router assumptions 299 In order to achieve its security goals, BGPsec assumes additional 300 capabilities in routers. In particular, BGPsec involves adding 301 digital signatures to BGP update messages, which will significantly 302 increase the size of these messages. Therefore, an AS that wishes to 303 receive BGPsec update messages will require additional memory in its 304 routers to store (e.g., in ADJ RIBs) the data conveyed in these 305 larger update messages. Additionally, the design of BGPsec assumes 306 that an AS that elects to receive BGPsec update messages will do some 307 cryptographic signature verification at its edge router. This 308 verification may require additional capability in these edge routers. 310 Additionally, BGPsec requires that all BGPsec speakers will support 311 4-byte AS Numbers [RFC4893]. This is because the co-existence 312 strategy for 4-byte AS numbers and legacy 2-byte AS speakers that 313 gives special meaning to AS 23456 is incompatible with the security 314 the security properties that BGPsec seeks to provide. 316 For this initial version of BGPsec, optimizations to minimize the 317 size of BGPsec updates or the processing required in edge routers 318 have not been considered. Such optimizations may be considered in the 319 future. 321 Note also that the design of BGPsec allows an AS to send BGPsec 322 update messages (thus obtaining protection for routes it originates) 323 without receiving BGPsec update messages. An AS that only sends, and 324 does not receive, BGPsec update messages will require much less 325 capability in its edge routers to deploy BGPsec. In particular, a 326 router that only sends BGPsec update messages does not need 327 additional memory to store larger updates and requires only minimal 328 cryptographic capability (as generating one signature per outgoing 329 update requires less computation than verifying multiple signatures 330 on each incoming update message). See [I-D.sidr-bgpsec-ops] for 331 further discussion related to Edge ASes that do not provide transit. 333 4.3. BGPsec and consistency of externally visible data 335 Finally note that, by design, BGPsec prevents parties that propagate 336 route advertisements from including inconsistent or erroneous 337 information within the AS-Path (without detection). In particular, 338 this means that any deployed scenarios in which a BGP speaker 339 constructs such an inconsistent or erroneous AS Path attribute will 340 break when BGPsec is used. 342 For example, when BGPsec is not used, it is possible for a single 343 autonomous system to have one peering session where it identifies 344 itself as AS 111 and a second peering session where it identifies 345 itself as AS 222. In such a case, it might receive route 346 advertisements from the first peering session (as AS 111) and then 347 add AS 222 (but not AS 111) to the AS-Path and propagate them within 348 the second peering session. 350 Such behavior may very well be innocent and performed with the 351 consent of the legitimate holder of both AS 111 and 222. However, it 352 is indistinguishable from the following man-in-the-middle attack 353 performed by a malicious AS 222. First, the malicious AS 222 354 impersonates AS 111 in the first peering session (essentially 355 stealing a route advertisement intended for AS 111). The malicious AS 356 222 then inserts itself into the AS path and propagates the update to 357 its peers. 359 Therefore, when BGPsec is used, such an autonomous system would 360 either need to assert a consistent AS number in all external peering 361 sessions, or else it would need to add both AS 111 and AS 222 to the 362 AS-Path (along with appropriate signatures) for route advertisements 363 that it receives from the first peering session and propagates within 364 the second peering session. See [I-D.sidr-as-migration] for a 365 detailed discussion of how to reasonably manage AS number migrations 366 while using BGPsec. 368 5. Security Considerations 370 This document provides an overview of BPSEC; it does not define the 371 BGPsec extension to BGP. The BGPsec extension is defined in [I- 372 D.sidr-bgpsec-protocol]. The threat model for the BGPsec is 373 described in [I-D.sidr-bgpsec-threats]. 375 6. IANA Considerations 377 None. 379 7.1. Normative References 381 [RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway 382 Protocol 4 (BGP-4)", RFC 4271, January 2006. 384 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 385 Numbers", RFC 4893, May 2007. 387 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 388 with BGP-4", RFC 5492, February 2009. 390 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 391 Secure Internet Routing", February 2012. 393 [RFC6483] Huston, G., and G. Michaelson, "Validation of Route 394 Origination using the Resource Certificate PKI and ROAs", February 395 2012. 397 [RFC7132] Kent, S., and A. Chi, "Threat Model for BGP Path Security", 398 RFC 7132, February 2014. 400 [RFC7115] Bush, R., "RPKI-Based Origin Validation Operation", RFC 401 7115, January 2014. 403 [I-D.sidr-bgpsec-protocol] Lepinski, M., Ed., "BPSEC Protocol 404 Specification", draft-ietf-sidr-bgpsec-protocol, work-in-progress. 406 [I-D.sidr-bgpsec-ops] Bush, R., "BGPsec Operational Considerations", 407 draft-ietf-sidr-bgpsec-ops, work-in-progress. 409 [I-D.sidr-bgpsec-algs] Turner, S., "BGP Algorithms, Key Formats, & 410 Signature Formats", draft-ietf-sidr-bgpsec-algs, work-in-progress. 412 [I-D.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile 413 for BGPsec Router Certificates, Certificate Revocation Lists, and 414 Certification Requests", draft-sidr-bgpsec-pki-profiles, work-in- 415 progress. 417 [I-D.sidr-as-migration] George, W. and S. Murphy, "BGPSec 418 Considerations for AS Migration", draft-ietf-sidr-as-migration, work- 419 in-progress. 421 7.2. Informative References 423 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 424 4272, January 2006 426 [I-D.sriram-bgpsec-design-choices] Sriram, K., "BGPsec Design Choices 427 and Summary of Supporting Discussions", draft-sriram-bgpsec-design- 428 choices, work-in-progress. 430 [RFC7353] Bellovin, S., R. Bush, and D. Ward, "Security Requirements 431 for BGP Path Validation", RFC 7353, August 2014. 433 Author's' Addresses 435 Matt Lepinski 436 BBN Technologies 437 10 Moulton Street 438 Cambridge MA 02138 440 Email: mlepinski.ietf@gmail.com 442 Sean Turner 443 IECA, Inc. 444 3057 Nutley Street, Suite 106 445 Fairfax, VA 22031 447 Email: turners@ieca.com