idnits 2.17.1 draft-ietf-sidr-bgpsec-overview-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 16, 2013) is 3784 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 101, but not defined == Missing Reference: 'I-D.turner-sidr-bgpsec-algs' is mentioned on line 108, but not defined == Missing Reference: 'RFC 4272' is mentioned on line 126, but not defined == Missing Reference: 'RFC 5492' is mentioned on line 181, but not defined == Unused Reference: 'RFC4271' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'I-D.sidr-origin-ops' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'I-D.sidr-bgpsec-algs' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'I-D.sidr-bgpsec-pki-profiles' is defined on line 408, but no explicit reference was found in the text == Unused Reference: 'RFC4272' is defined on line 415, 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: 2 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: June 16, 2014 IECA 6 December 16, 2013 8 An Overview of BGPSEC 9 draft-ietf-sidr-bgpsec-overview-04.txt 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 November 8, 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...................................................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 . [I-D.sidr-bgpsec-threats]: 84 A threat model describing the security context in which BGPSEC 85 is intended to operate. 87 . [I-D.sidr-bgpsec-reqs]: 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-bgpsec-ops]: 99 An informational document describing operational considerations. 101 . [I-D.turner-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.turner-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 author 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, [RFC 4272]). 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 valid ROAs can be used by BGP speakers 138 to determine whether a received route was originated by an AS 139 authorized to originate that route (see [RFC6483] and [I-D.sidr- 140 origin-ops]). 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 certain mis- 145 utilizing RPKI data could detect this error and decline to select 146 these mis-originated routes. However, use of RPKI data alone provides 147 little or no protection against a sophisticated attacker. Such an 148 attacker could, for example, conduct a route hijacking attack by 149 appending an authorized origin AS to an otherwise illegitimate AS 150 Path. (See [I-D.sidr-bgpsec-threats] for a detailed discussion of the 151 BGPSEC threat model.) 153 BGPSEC extends the RPKI by adding an additional type of certificate, 154 referred to as a BGPSEC router certificate, that binds an AS number 155 to a public signature verification key, the corresponding private key 156 of which is held by one or more BGP speakers within this AS. Private 157 keys corresponding to public keys in such certificates can then be 158 used within BGPSEC to enable BGP speakers to sign on behalf of their 159 AS. The certificates thus allow a relying party to verify that a 160 BGPSEC signature was produced by a BGP speaker belonging to a given 161 AS. The goal of BGPSEC is to use signatures to protect the AS Path 162 attribute of BGP update messages so that a BGP speaker can assess the 163 validity of the AS Path in update messages that it receives. 165 3. BGPSEC Operation 167 The core of BGPSEC is a new optional (non-transitive) attribute, 168 called BGPSEC_Path_Signatures. This attribute consists of a sequence 169 of digital signatures, one for each AS in the AS Path of a BGPSEC 170 update message. (The use of this new attribute is formally specified 171 in [I-D.sidr-bgpsec-protocol].) A new signature is added to this 172 sequence each time an update message leaves an AS. The signature is 173 constructed so that any tampering with the AS path or Network Layer 174 Reachability Information (NLRI) in the BGPSEC update message will 175 result in the recipient being able to detect that the update is 176 invalid. 178 3.1. Negotiation of BGPSEC 180 The use of BGPSEC is negotiated using BGP capability advertisements 181 [RFC 5492]. Upon opening a BGP session with a peer, BGP speakers who 182 support (and wish to use) BGPSEC include a newly-defined capability 183 in the OPEN message. 185 The use of BGPSEC is negotiated separately for each address family. 186 This means that a BGP speaker could, for example, elect to use BGPSEC 187 for IPv6, but not for IPv4 (or vice versa). Additionally, the use of 188 BGPSEC is negotiated separately in the send and receive directions. 189 This means that a BGP speaker could, for example, indicate support 190 for sending BGPSEC update messages but require that messages it 191 receives be traditional (non-BGPSEC) update message. (To see why such 192 a feature might be useful, see Section 4.2.) 194 If the use of BGPSEC is negotiated in a BGP session (in a given 195 direction, for a given address family) then both BGPSEC update 196 messages (ones that contain the BGPSEC_Path_Signature attribute) and 197 traditional BGP update messages (that do not contain this attribute) 198 can be sent within the session. 200 If a BGPSEC-capable BGP speaker finds that its peer does not support 201 receiving BGPSEC update messages, then the BGP speaker must remove 202 existing BGPSEC_Path_Signatures attribute from any update messages it 203 sends to this peer. 205 3.2. Update signing and validation 207 When a BGP speaker originates a BGPSEC update message, it creates a 208 BGPSEC_Path_Signatures attribute containing a single signature. The 209 signature protects the Network Layer Reachability Information (NLRI), 210 the AS number of the originating AS, the AS number of the peer AS to 211 whom the update message is being sent, and a few other pieces of data 212 necessary for security guarantees. Note that the NLRI in a BGPSEC 213 update message is restricted to contain only a single prefix. 215 When a BGP speaker receives a BGPSEC update message and wishes to 216 propagate the route advertisement contained in the update to an 217 external peer, it adds a new signature to the BGPSEC_Path_Signatures 218 attribute. This signature protects everything protected by the 219 previous signature, plus the AS number of the new peer to whom the 220 update message is being sent. 222 Each BGP speaker also adds a reference, called a Subject Key 223 Identifier (SKI), to its BGPSEC Router certificate. The SKI is used 224 by a recipient to select the public key (and selected router 225 certificate data) needed for validation. 227 As an example, consider the following case in which an advertisement 228 for 192.0.2/24 is originated by AS 1, which sends the route to AS 2, 229 which sends it to AS 3, which sends it to AS 4. When AS 4 receives a 230 BGPSEC update message for this route, it will contain the following 231 data: 233 . NLRI : 192.0.2/24 235 . AS_Path : 3 2 1 237 . BGPSEC_Path_Signatures Attribute with 3 signatures : 238 o Signature from AS 1 protecting 239 192.0.2/24, AS 1 and AS 2 241 o Signature from AS 2 protecting 243 Everything AS 1's signature protected, and AS 3 245 o Signature from AS 3 protecting 247 Everything AS 2's signature protected, and AS 4 249 When a BGPSEC update message is received by a BGP speaker, the BGP 250 speaker can validate the message as follows. For each signature, the 251 BGP speaker first needs to determine if there is a valid RPKI Router 252 certificate matching the SKI and containing the appropriate AS 253 number. (This would typically be done by looking up the SKI in a 254 cache of data extracted from valid RPKI objects. A cache allows 255 certificate validation to be handled via an asynchronous process, 256 which might execute on another device.) 258 The BGP speaker then verifies the signature using the public key from 259 this BGPSEC router certificate. If all the signatures can be verified 260 in this fashion, the BGP speaker is assured that the update message 261 it received actually came via the path specified in the AS_Path 262 attribute. Finally, the BGP speaker can check whether there exists a 263 valid ROA in the RPKI linking the origin AS to the prefix in the 264 NLRI. If such a valid ROA exists the BGP speaker is further assured 265 that the AS at the beginning of the validated path was authorized to 266 originate routes to the given prefix. 268 In the above example, upon receiving the BGPSEC update message, a BGP 269 speaker for AS 4 would first check to make sure that there is a valid 270 ROA authorizing AS 1 to originate advertisements for 192.0.2/24. It 271 would then look at the SKI for the first signature and see if this 272 corresponds to a valid BGPSEC Router certificate for AS 1. Next, it 273 would then verify the first signature using the key found in this 274 valid certificate. Finally, it would repeat this process for the 275 second and third signatures, checking to see that there are valid 276 BGPSEC router certificates for AS 2 and AS 3 (respectively) and that 277 the signatures can be verified with the keys found in these 278 certificates. 280 4. Design and Deployment Considerations 282 In this section we briefly discuss several additional topics that 283 commonly arise in the discussion of BGPSEC. 284 4.1. Disclosure of topology information 286 A key requirement in the design of BGPSEC was that BGPSEC not 287 disclose any new information about BGP peering topology. Since many 288 ISPs feel peering topology data is proprietary, further disclosure of 289 it would inhibit BGPSEC adoption. 291 In particular, the topology information that can be inferred from 292 BGPSEC update messages is exactly the same as that which can be 293 inferred from equivalent (non-BGPSEC) BGP update messages. 295 4.2. BGPSEC router assumptions 297 In order to achieve its security goals, BGPSEC assumes additional 298 capabilities in routers. In particular, BGPSEC involves adding 299 digital signatures to BGP update messages, which will significantly 300 increase the size of these messages. Therefore, an AS that wishes to 301 receive BGPSEC update messages will require additional memory in its 302 routers to store (e.g., in ADJ RIBs) the data conveyed in these large 303 update messages. Additionally, the design of BGPSEC assumes that an 304 AS that elects to receive BGPSEC update messages will do some 305 cryptographic signature verification at its edge router. This 306 verification will likely require additional capability in these edge 307 routers. 309 Additionally, BGPSEC requires that all BGPSEC speakers will support 310 4-byte AS Numbers [RFC4893]. This is because the co-existence 311 strategy for 4-byte AS numbers and legacy 2-byte AS speakers that 312 gives special meaning to AS 23456 is incompatible with the security 313 the security properties that BGPSEC seeks to provide. 315 For this initial version of BGPSEC, optimizations to minimize the 316 size of BGPSEC updates or the processing required in edge routers 317 have not been considered. Such optimizations may be considered in the 318 future. 320 Note also that the design of BGPSEC allows an AS to send BGPSEC 321 update messages (thus obtaining protection for routes it originates) 322 without receiving BGPSEC update messages. An AS that only sends, and 323 does not receive, BGPSEC update messages will require much less 324 capability in its edge routers to deploy BGPSEC. In particular, a 325 router that only sends BGPSEC update messages does not need 326 additional memory to store large updates and requires only minimal 327 cryptographic capability (as generating one signature per outgoing 328 update requires less computation than verifying multiple signatures 329 on each incoming update message). See [I-D.sidr-bgpsec-ops] for 330 further discussion related to Edge ASes that do not provide transit.) 331 4.3. BGPSEC and consistency of externally visible data 333 Finally note that, by design, BGPSEC prevents parties that propagate 334 route advertisements from including inconsistent or erroneous 335 information within the AS-Path (without detection). In particular, 336 this means that any deployed scenarios in which a BGP speaker 337 constructs such an inconsistent or erroneous AS Path attribute will 338 break when BGPSEC is used. 340 For example, when BGPSEC is not used, it is possible for a single 341 autonomous system to have one peering session where it identifies 342 itself as AS 111 and a second peering session where it identifies 343 itself as AS 222. In such a case, it might receive route 344 advertisements from the first peering session (as AS 111) and then 345 add AS 222 (but not AS 111) to the AS-Path and propagate them within 346 the second peering session. 348 Such behavior may very well be innocent and performed with the 349 consent of the legitimate holder of both AS 111 and 222. However, it 350 is indistinguishable from the following man-in-the-middle attack 351 performed by a malicious AS 222. First, the malicious AS 222 352 impersonates AS 111 in the first peering session (essentially 353 stealing a route advertisement intended for AS 111). The malicious AS 354 222 then inserts itself into the AS path and propagates the update to 355 its peers. 357 Therefore, when BGPSEC is used, such an autonomous system would 358 either need to assert a consistent AS number in all external peering 359 sessions, or else it would need to add both AS 111 and AS 222 to the 360 AS-Path (along with appropriate signatures) for route advertisements 361 that it receives from the first peering session and propagates within 362 the second peering session. 364 5. Security Considerations 366 This document provides an overview of BPSEC; it does not define the 367 BGPSEC extension to BGP. The BGPSEC extension is defined in [I- 368 D.sidr-bgpsec-protocol]. The threat model for the BGPSEC is 369 described in [I-D.sidr-bgpsec-threats]. 371 6. IANA Considerations 373 None. 375 7.1. Normative References 377 [RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway 378 Protocol 4 (BGP-4)", RFC 4271, January 2006. 380 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 381 Numbers", RFC 4893, May 2007. 383 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 384 with BGP-4", RFC 5492, February 2009. 386 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 387 Secure Internet Routing", February 2012. 389 [RFC6483] Huston, G., and G. Michaelson, "Validation of Route 390 Origination using the Resource Certificate PKI and ROAs", February 391 2012. 393 [I-D.sidr-origin-ops] Bush, R., "RPKI-Based Origin Validation 394 Operation", draft-ietf-sidr-origin-ops, work-in-progress. 396 [I-D.sidr-bgpsec-threats] Kent, S., and A. Chi, "Threat Model for BGP 397 Path Security", draft-ietf-sidr-bgpsec-threats, work-in-progress. 399 [I-D.sidr-bgpsec-protocol] Lepinski, M., Ed., "BPSEC Protocol 400 Specification", draft-ietf-sidr-bgpsec-protocol, work-in-progress. 402 [I-D.sidr-bgpsec-ops] Bush, R., "BGPSEC Operational Considerations", 403 draft-ietf-sidr-bgpsec-ops, work-in-progress. 405 [I-D.sidr-bgpsec-algs] Turner, S., "BGP Algorithms, Key Formats, & 406 Signature Formats", draft-ietf-sidr-bgpsec-algs, work-in-progress. 408 [I-D.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, S., "A 409 Profile for BGPSEC Router Certificates, Certificate Revocation Lists, 410 and Certification Requests", draft-sidr-bgpsec-pki-profiles, work-in- 411 progress. 413 7.2. Informative References 415 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 416 4272, January 2006 418 [I-D.sriram-bgpsec-design-choices] Sriram, K., "BGPSEC Design Choices 419 and Summary of Supporting Discussions", draft-sriram-bgpsec-design- 420 choices, work-in-progress. 422 [I-D.sidr-bgpsec-reqs] Bellovin, S., R. Bush, and D. Ward, "Security 423 Requirements for BGP Path Validation", draft-ietf-sidr-bgpsec-reqs, 424 work-in-progress. 426 Author's' Addresses 427 Matt Lepinski 428 BBN Technologies 429 10 Moulton Street 430 Cambridge MA 02138 432 Email: mlepinski.ietf@gmail.com 434 Sean Turner 435 IECA, Inc. 436 3057 Nutley Street, Suite 106 437 Fairfax, VA 22031 439 Email: turners@ieca.com