idnits 2.17.1 draft-ietf-sidr-bgpsec-overview-03.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 (July 15, 2013) is 3938 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 4271' is mentioned on line 75, but not defined == Missing Reference: 'I-D.turner-sidr-bgpsec-pki-profiles' is mentioned on line 95, but not defined == Missing Reference: 'I-D.turner-sidr-bgpsec-algs' is mentioned on line 102, but not defined == Missing Reference: 'RFC 4272' is mentioned on line 123, but not defined == Missing Reference: 'RFC 5492' is mentioned on line 180, but not defined == Unused Reference: 'RFC4271' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'I-D.sidr-origin-ops' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'I-D.sidr-bgpsec-algs' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'I-D.sidr-bgpsec-pki-profiles' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'RFC4272' is defined on line 420, 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. -------------------------------------------------------------------------------- 1 Network Working Group M. Lepinski 2 Internet Draft BBN Technologies 3 Intended status: Informational S. Turner 4 Expires: January 15, 2014 IECA 5 July 15, 2013 7 An Overview of BGPSEC 8 draft-ietf-sidr-bgpsec-overview-03.txt 10 Abstract 12 This document provides an overview of a security extension to the 13 Border Gateway Protocol (BGP) referred to as BGPSEC. BGPSEC improves 14 security for BGP routing. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on November 8, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction...................................................2 57 2. Background.....................................................3 58 3. BGPSEC Operation...............................................4 59 3.1. Negotiation of BGPSEC.....................................4 60 3.2. Update signing and validation.............................5 61 4. Design and Deployment Considerations...........................6 62 4.1. Disclosure of topology information........................7 63 4.2. BGPSEC router assumptions.................................7 64 4.3. BGPSEC and consistency of externally visible data.........8 65 5. Security Considerations........................................8 66 6. IANA Considerations............................................8 67 7. References.....................................................9 68 7.1. Normative References......................................9 69 7.2. Informative References....................................9 71 1. Introduction 73 BGPSEC (Border Gateway Protocol Security) is an extension to the 74 Border Gateway Protocol (BGP) that provides improved security for BGP 75 routing [RFC 4271]. 77 A comprehensive discussion of BGPSEC is provided in the following set 78 of documents: 80 . [I-D.sidr-bgpsec-threats]: 82 A threat model describing the security context in which BGPSEC 83 is intended to operate. 85 . [I-D.sidr-bgpsec-protocol]: 87 A standards track document specifying the BGPSEC extension to 88 BGP. 90 . [I-D.sidr-bgpsec-ops]: 92 An informational document describing operational considerations 93 for BGPSEC deployment. 95 . [I-D.turner-sidr-bgpsec-pki-profiles] 97 A standards track document specifying a profile for X.509 98 certificates that bind keys used in BGPSEC to Autonomous System 99 numbers, as well as associated Certificate Revocation Lists 100 (CRLs), and certificate requests. 102 . [I-D.turner-sidr-bgpsec-algs] 104 A standards track document specifying suites of signature and 105 digest algorithms for use in BGPSEC. 107 . [I-D.sriram-bgpsec-design-choices] 109 An informational document describing the choices that were made 110 by the author team prior to the publication of the -00 version 111 of draft-ietf-sidr-bgpsec-protocol. Discussion of design choices 112 made since the publication of the -00 can be found in the 113 archives of the SIDR working group mailing list. 115 The remainder of this document contains a brief overview of BGPSEC 116 and its envisioned usage. 118 2. Background 120 The motivation for developing BGPSEC is that BGP does not include 121 mechanisms that allow an Autonomous System (AS) to verify the 122 legitimacy and authenticity of BGP route advertisements (see for 123 example, [RFC 4272]). 125 The Resource Public Key Infrastructure (RPKI), described in 126 [RFC6480], provides a first step towards addressing the validation of 127 BGP routing data. RPKI resource certificates are issued to the 128 holders of AS number and IP address resources, providing a binding 129 between these resources and cryptographic keys that can be used to 130 verify digital signatures. Additionally, the RPKI architecture 131 specifies a digitally signed object, a Route Origination 132 Authorization (ROA), that allows holders of IP address resources to 133 authorize specific ASes to originate routes (in BGP) to these 134 resources. Data extracted from valid ROAs can be used by BGP speakers 135 to determine whether a received route was originated by an AS 136 authorized to originate that route (see [RFC6483] and [I-D.sidr- 137 origin-ops]). 139 By instituting a local policy that prefers routes with origins 140 validated using RPKI data (versus routes to the same prefix that 141 cannot be so validated) an AS can protect itself from certain mis- 142 origination attacks. For example, if a BGP speaker accidently (due to 143 misconfiguration) originates routes to the wrong prefixes, ASes 144 utilizing RPKI data could detect this error and decline to select 145 these mis-originated routes. However, use of RPKI data alone provides 146 little or no protection against a sophisticated attacker. Such an 147 attacker could, for example, conduct a route hijacking attack by 148 appending an authorized origin AS to an otherwise illegitimate AS 149 Path. (See [I-D.sidr-bgpsec-threats] for a detailed discussion of the 150 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 key 155 of which is held by one or more BGP speakers within this AS. Private 156 keys corresponding to public keys in such certificates can then be 157 used within BGPSEC to enable BGP speakers to sign on behalf of their 158 AS. The certificates thus allow a relying party to verify that a 159 BGPSEC signature was produced by a BGP speaker belonging to a given 160 AS. The goal of BGPSEC is to use signatures to protect the AS Path 161 attribute of BGP update messages so that a BGP speaker can assess the 162 validity of the AS Path 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_Signatures. This attribute consists of a sequence 168 of digital signatures, one for each AS in the AS Path of a BGPSEC 169 update message. (The use of this new attribute is formally specified 170 in [I-D.sidr-bgpsec-protocol].) A new signature is added to this 171 sequence each time an update message leaves an AS. The signature is 172 constructed so that any tampering with the AS path or Network Layer 173 Reachability Information (NLRI) in the BGPSEC update message will 174 result in the recipient being able to detect that the update is 175 invalid. 177 3.1. Negotiation of BGPSEC 179 The use of BGPSEC is negotiated using BGP capability advertisements 180 [RFC 5492]. Upon opening a BGP session with a peer, BGP speakers who 181 support (and wish to use) BGPSEC include a newly-defined capability 182 in the OPEN message. 184 The use of BGPSEC is negotiated separately for each address family. 185 This means that a BGP speaker could, for example, elect to use BGPSEC 186 for IPv6, but not for IPv4 (or vice versa). Additionally, the use of 187 BGPSEC is negotiated separately in the send and receive directions. 188 This means that a BGP speaker could, for example, indicate support 189 for sending BGPSEC update messages but require that messages it 190 receives be traditional (non-BGPSEC) update message. (To see why such 191 a feature might be useful, see Section 4.2.) 193 If the use of BGPSEC is negotiated in a BGP session (in a given 194 direction, for a given address family) then both BGPSEC update 195 messages (ones that contain the BGPSEC_Path_Signature attribute) and 196 traditional BGP update messages (that do not contain this attribute) 197 can be sent within the session. 199 If a BGPSEC-capable BGP speaker finds that its peer does not support 200 receiving BGPSEC update messages, then the BGP speaker must remove 201 existing BGPSEC_Path_Signatures attribute from any update messages it 202 sends to this peer. 204 3.2. Update signing and validation 206 When a BGP speaker originates a BGPSEC update message, it creates a 207 BGPSEC_Path_Signatures attribute containing a single signature. The 208 signature protects the Network Layer Reachability Information (NLRI), 209 the AS number of the originating AS, the AS number of the peer AS to 210 whom the update message is being sent, and a few other pieces of data 211 necessary for security guarantees. Note that the NLRI in a BGPSEC 212 update message is restricted to contain only a single prefix. 214 When a BGP speaker receives a BGPSEC update message and wishes to 215 propagate the route advertisement contained in the update to an 216 external peer, it adds a new signature to the BGPSEC_Path_Signatures 217 attribute. This signature protects everything protected by the 218 previous signature, plus the AS number of the new peer to whom the 219 update message is being sent. 221 Each BGP speaker also adds a reference, called a Subject Key 222 Identifier (SKI), to its BGPSEC Router certificate. The SKI is used 223 by a recipient to select the public key (and selected router 224 certificate data) needed for validation. 226 As an example, consider the following case in which an advertisement 227 for 192.0.2/24 is originated by AS 1, which sends the route to AS 2, 228 which sends it to AS 3, which sends it to AS 4. When AS 4 receives a 229 BGPSEC update message for this route, it will contain the following 230 data: 232 . NLRI : 192.0.2/24 234 . AS_Path : 3 2 1 236 . BGPSEC_Path_Signatures Attribute with 3 signatures : 238 o Signature from AS 1 protecting 240 192.0.2/24, AS 1 and AS 2 242 o Signature from AS 2 protecting 244 Everything AS 1's signature protected, and AS 3 246 o Signature from AS 3 protecting 248 Everything AS 2's signature protected, and AS 4 250 When a BGPSEC update message is received by a BGP speaker, the BGP 251 speaker can validate the message as follows. For each signature, the 252 BGP speaker first needs to determine if there is a valid RPKI Router 253 certificate matching the SKI and containing the appropriate AS 254 number. (This would typically be done by looking up the SKI in a 255 cache of data extracted from valid RPKI objects. A cache allows 256 certificate validation to be handled via an asynchronous process, 257 which might execute on another device.) 259 The BGP speaker then verifies the signature using the public key from 260 this BGPSEC router certificate. If all the signatures can be verified 261 in this fashion, the BGP speaker is assured that the update message 262 it received actually came via the path specified in the AS_Path 263 attribute. Finally, the BGP speaker can check whether there exists a 264 valid ROA in the RPKI linking the origin AS to the prefix in the 265 NLRI. If such a valid ROA exists the BGP speaker is further assured 266 that the AS at the beginning of the validated path was authorized to 267 originate routes to the given prefix. 269 In the above example, upon receiving the BGPSEC update message, a BGP 270 speaker for AS 4 would first check to make sure that there is a valid 271 ROA authorizing AS 1 to originate advertisements for 192.0.2/24. It 272 would then look at the SKI for the first signature and see if this 273 corresponds to a valid BGPSEC Router certificate for AS 1. Next, it 274 would then verify the first signature using the key found in this 275 valid certificate. Finally, it would repeat this process for the 276 second and third signatures, checking to see that there are valid 277 BGPSEC router certificates for AS 2 and AS 3 (respectively) and that 278 the signatures can be verified with the keys found in these 279 certificates. 281 4. Design and Deployment Considerations 283 In this section we briefly discuss 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 large 305 update messages. Additionally, the design of BGPSEC assumes that an 306 AS that elects to receive BGPSEC update messages will do some 307 cryptographic signature verification at its edge router. This 308 verification will likely require additional capability in these edge 309 routers. 311 Additionally, BGPSEC requires that all BGPSEC speakers will support 312 4-byte AS Numbers [RFC4893]. This is because the co-existence 313 strategy for 4-byte AS numbers and legacy 2-byte AS speakers that 314 gives special meaning to AS 23456 is incompatible with the security 315 the security properties that BGPSEC seeks to provide. 317 For this initial version of BGPSEC, optimizations to minimize the 318 size of BGPSEC updates or the processing required in edge routers 319 have not been considered. Such optimizations may be considered in the 320 future. 322 Note also that the design of BGPSEC allows an AS to send BGPSEC 323 update messages (thus obtaining protection for routes it originates) 324 without receiving BGPSEC update messages. An AS that only sends, and 325 does not receive, BGPSEC update messages will require much less 326 capability in its edge routers to deploy BGPSEC. In particular, a 327 router that only sends BGPSEC update messages does not need 328 additional memory to store large updates and requires only minimal 329 cryptographic capability (as generating one signature per outgoing 330 update requires less computation than verifying multiple signatures 331 on each incoming update message). See [I-D.sidr-bgpsec-ops] for 332 further discussion related to Edge ASes that do not provide transit.) 334 4.3. BGPSEC and consistency of externally visible data 336 Finally note that, by design, BGPSEC prevents parties that propagate 337 route advertisements from including inconsistent or erroneous 338 information within the AS-Path (without detection). In particular, 339 this means that any deployed scenarios in which a BGP speaker 340 constructs such an inconsistent or erroneous AS Path attribute will 341 break when BGPSEC is used. 343 For example, when BGPSEC is not used, it is possible for a single 344 autonomous system to have one peering session where it identifies 345 itself as AS 111 and a second peering session where it identifies 346 itself as AS 222. In such a case, it might receive route 347 advertisements from the first peering session (as AS 111) and then 348 add AS 222 (but not AS 111) to the AS-Path and propagate them within 349 the second peering session. 351 Such behavior may very well be innocent and performed with the 352 consent of the legitimate holder of both AS 111 and 222. However, it 353 is indistinguishable from the following man-in-the-middle attack 354 performed by a malicious AS 222. First, the malicious AS 222 355 impersonates AS 111 in the first peering session (essentially 356 stealing a route advertisement intended for AS 111). The malicious AS 357 222 then inserts itself into the AS path and propagates the update to 358 its peers. 360 Therefore, when BGPSEC is used, such an autonomous system would 361 either need to assert a consistent AS number in all external peering 362 sessions, or else it would need to add both AS 111 and AS 222 to the 363 AS-Path (along with appropriate signatures) for route advertisements 364 that it receives from the first peering session and propagates within 365 the second peering session. 367 5. Security Considerations 369 This document provides an overview of BPSEC; it does not define the 370 BGPSEC extension to BGP. The BGPSEC extension is defined in [I- 371 D.sidr-bgpsec-protocol]. The threat model for the BGPSEC is 372 described in [I-D.sidr-bgpsec-threats]. 374 6. IANA Considerations 376 None. 378 7. References 380 7.1. Normative References 382 [RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway 383 Protocol 4 (BGP-4)", RFC 4271, January 2006. 385 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 386 Numbers", RFC 4893, May 2007. 388 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 389 with BGP-4", RFC 5492, February 2009. 391 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 392 Secure Internet Routing", February 2012. 394 [RFC6483] Huston, G., and G. Michaelson, "Validation of Route 395 Origination using the Resource Certificate PKI and ROAs", February 396 2012. 398 [I-D.sidr-origin-ops] Bush, R., "RPKI-Based Origin Validation 399 Operation", draft-ietf-sidr-origin-ops, work-in-progress. 401 [I-D.sidr-bgpsec-threats] Kent, S., "Threat Model for BGP Path 402 Security", draft-ietf-sidr-bgpsec-threats, work-in-progress. 404 [I-D.sidr-bgpsec-protocol] Lepinski, M., Ed., "BPSEC Protocol 405 Specification", draft-ietf-sidr-bgpsec-protocol, work-in-progress. 407 [I-D.sidr-bgpsec-ops] Bush, R., "BGPSEC Operational Considerations", 408 draft-ietf-sidr-bgpsec-ops, work-in-progress. 410 [I-D.sidr-bgpsec-algs] Turner, S., "BGP Algorithms, Key Formats, & 411 Signature Formats", draft-ietf-sidr-bgpsec-algs, work-in-progress. 413 [I-D.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, S., "A 414 Profile for BGPSEC Router Certificates, Certificate Revocation Lists, 415 and Certification Requests", draft-sidr-bgpsec-pki-profiles, work-in- 416 progress. 418 7.2. Informative References 420 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 421 4272, January 2006 423 [I-D.sriram-bgpsec-design-choices] Sriram, K., "BGPSEC Design Choices 424 and Summary of Supporting Discussions", draft-sriram-bgpsec-design- 425 choices, work-in-progress. 427 Author's' Addresses 429 Matt Lepinski 430 BBN Technologies 431 10 Moulton Street 432 Cambridge MA 02138 434 Email: mlepinski@bbn.com 436 Sean Turner 437 IECA, Inc. 438 3057 Nutley Street, Suite 106 439 Fairfax, VA 22031 441 Email: turners@ieca.com