idnits 2.17.1 draft-white-sobgp-architecture-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == Mismatching filename: the document gives the document name as 'draft-white-sobgparchitecture-00', but the file name used is 'draft-white-sobgp-architecture-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 85: '...cates MAY be distributed using the mechanisms described in [SOBGP-BGPTRANSPORT], or some other mechanism. Once these certificates have...' RFC 2119 keyword, line 107: '...d, a BGP speaker MUST have access to t...' RFC 2119 keyword, line 146: '...oBGP information MUST use the same mec...' RFC 2119 keyword, line 156: '...the higher value MUST be preferred. An...' RFC 2119 keyword, line 171: '... method selected MUST be consistent th...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2004) is 7316 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BGP-MD5' is mentioned on line 319, but not defined == Missing Reference: 'GTSH' is mentioned on line 53, but not defined == Missing Reference: 'SOBGP-BGPTRANSPORT' is mentioned on line 85, but not defined == Missing Reference: 'ESP' is mentioned on line 314, but not defined == Missing Reference: 'AH' is mentioned on line 320, but not defined ** Obsolete normative reference: RFC 1771 (ref. 'BGP') (Obsoleted by RFC 4271) == Outdated reference: A later version (-02) exists of draft-ng-sobgp-bgp-extensions-01 -- Possible downref: Normative reference to a draft: ref. 'SOBGP-BGPEXT' == Outdated reference: A later version (-04) exists of draft-weis-sobgp-certificates-01 -- Possible downref: Normative reference to a draft: ref. 'SOBGP-CERTIFICATE' == Outdated reference: A later version (-09) exists of draft-white-pathconsiderations-02 == Outdated reference: A later version (-02) exists of draft-retana-bgp-custom-decision-00 Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Russ White 3 Internet Draft (editor) 4 Expiration Date: October 2004 Cisco Systems 5 File Name: draft-white-sobgparchitecture-00.txt April 2004 7 Architecture and Deployment Considerations for Secure Origin BGP (soBGP) 8 draft-white-sobgparchitecture-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its Areas, and its Working Groups. Note that other 17 groups may also distribute working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http//www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http//www.ietf.org/shadow.html. 31 Abstract 33 There is a great deal of concern over the security of the Border 34 Gateway Protocol, which is used to provide routing information to the 35 Internet and other large internetworks. This draft provides an 36 architecture for a secure distributed registry of routing information 37 to address these concerns. The draft begins with an overview of the 38 operation of this system, and then follows with various deployment 39 scenerios, starting with what we believe will be the most common 40 deployment option. 42 1. Background 44 There are two fundamental pieces of a routing system that need to be 45 secured: 47 o Adjacencies between devices running the routing protocol 49 o Information carried within the routing protocol. 51 While security between BGP [BGP] speakers has been addressed in a 52 number of ways, including cryptographic authentication [BGP-MD5] and 53 limiting the attack radius through TTL mechanisms [GTSH], security 54 for the information carried within BGP is not considered a solved 55 problem. 57 This draft proposes a possible solution to securing the information 58 within BGP, using the certificates and protocol extensions proposed 59 in [SOBGP-BGPTRANSPORT], [SOBGP-CERTIFICATE], and [SOBGP-RADIUS]. 61 A large number of people contributed to this draft; we've tried to 62 include all of them here (but might have missed a few): James Ng, Tim 63 Gage, Alvaro Retana, Dave Cook, Brian Weis, and Iljitsch van Beijnum. 65 2. General Theory 67 soBGP provides a secure registry mechanism against which a BGP 68 speaker can check: 70 o The authorization of the AS listed as the originating AS in any 71 received update to advertise reachability to the prefix listed 72 in the update. 74 o The validity of the AS Path contained in the update. 76 We use the term validity in reference to the AS Path, in this docu- 77 ment, to indicate the plausibility of the AS Path listed. As shown in 78 [PATH-CONSIDER], it isn't possible to communicate authorization 79 through an AS Path; only the existence or nonexistance of the AS Path 80 listed can be proven. 82 soBGP operates by distributing a set of signed certificates, 83 described in [SOBGP-CERTIFICATE], containing the information required 84 to validate the two pieces of information given above. These certifi- 85 cates MAY be distributed using the mechanisms described in [SOBGP- 86 BGPTRANSPORT], or some other mechanism. Once these certificates have 87 been received and processed (signatures validated, etc, as described 88 in [SOBGP-CERTIFICATE], they form a database containing: 90 o A listing of IP address blocks and the AS authorized to ori- 91 ginate them. 93 o Policies related to specific prefixes and blocks of addresses. 95 o A list of autonomous systems connected to each autonomous system 96 within the internetwork. This connection list is used to build a 97 graph of AS interconnectivity within the internetwork, as 98 described in the section Building the AS Connectivity Graph, 99 below. 101 This effectively forms a secure registry of routing information which 102 can be used to check the validity of routing information received 103 from BGP peers. This database is termed the "authorization database." 104 No assumption about the location of the authorization database is 105 made within this document. 107 When soBGP is supported, a BGP speaker MUST have access to the 108 authorization database. Possible methods of access include: 110 o Have a local copy of this authorization database, and perform 111 the checkes described later in this document against that local 112 database. 114 o Pass received routing information to a locally maintained server 115 for validation against that server's copy of the authorization 116 database. 118 o Accept filters built from a copy of the authorization database 119 contained on a locally maintained server. 121 As BGP updates are processed, a security preference is assigned to 122 each prefix, as described further in the Security Preference section 123 of this document. BGP update processing is described in the Receiving 124 and Processing Updates section of this document. 126 3. soBGP Operation 128 Each section below provides detailed information on some aspect of 129 soBGP operation. 131 3.1. The Security Preference 133 Rather than simply noting a given prefix should be dropped (not 134 trusted) or retained (trusted), soBGP extends the concept of locally 135 generated and maintained policy in BGP by assigning each prefix a 136 Security Preference. This allows the local operator to drop prefixes 137 not meeting certain security criteria, while simply lowering their 138 preference for prefixes meeting some security criteria. This allows 139 operators some flexibility in their implementation of security poli- 140 cies, especially as the security system is being tested, or while the 141 security system isn't fully deployed. 143 While the amount by which the Security Preference is increased or 144 decreased for any operation described in this draft is locally signi- 145 ficant to the autonomous system. All devices processing routes 146 against soBGP information MUST use the same mechanisms and values of 147 the Security Preference to ensure consistent routing within the auto- 148 nomous system. 150 If the Security Preference is set to a value precluding a route from 151 further consideration in the decision process, the route should be 152 discarded at that point, rather than continuing with the decision 153 process. 155 The Security Preference value may be used to select among different 156 routes for the same prefix; the higher value MUST be preferred. Any 157 of the following methods may be used: 159 A Consider the Security Preference prior to calculating the degree 160 of preference [BGP] for a prefix. 162 B Assign the value of the Security Preference to any of the attri- 163 butes used in the Decision Process [BGP]. Care must be taken 164 with attributes for which the lower value is preferred. 166 C Use a Cost Community [COST] and its associated methods to con- 167 sider the Security Preference at any step in the Decision Pro- 168 cess [BGP] without overloading other attributes. Care must be 169 taken as the lowest value in a Cost Community is preferred. 171 The method selected MUST be consistent through the local Autonomous 172 System. 174 3.2. Building the AS Connectivity Graph 176 Each ASPolicyCert advertised by a member of the internetwork contains 177 a list of the autonomous systems the advertising AS is connected to, 178 along with possible policy information about that connection. From 179 this information, a graph of AS connectivity within the internetwork 180 is built. 182 Any AS can be used as the starting point for building this graph, 183 thus multiple disconnected graphs (representing section of the inter- 184 network running soBGP and providing interconnection information) are 185 possible. If every AS within the internetwork is providing intercon- 186 nection information, one graph can be built containing all the 187 internetwork's interconnections. 189 The process of creating this graph is: 191 o Examine the list of connected autonomous systems advertised by 192 the current AS. 194 o Examine the ASPolicyCert of each AS the current AS is advertis- 195 ing as connected, and determine if that AS is advertising a con- 196 nection back to the current AS. This is termed the two way con- 197 nectivity check. 199 o If the two way connectivity check passes, the connection SHOULD 200 be added to the interconnection graph, and marked as trustable. 202 o If the two way connectivity check fails, the connection MAY be 203 added to the interconnection graph, but marked so a lower secu- 204 rity preference will be assigned to AS_PATHs traversing this 205 link. 207 o Repeat this process for each ASPolicyCert in the authorization 208 database. 210 The resulting graph is called the internetwork graph. 212 3.3. Validating Routing Information 214 For each prefix within a given BGP UPDATE message: 216 o The local authorization database is examined, and the AuthCert 217 with the longest prefix length encompassing the range of 218 addresses described by the prefix is chosen. 220 o If there is no entry in the local authorization database which 221 encompasses the range of addresses described by the prefix, then 222 the route is said to be unverified, and should be handled 223 according to local policy (either discarded, or have its secu- 224 rity preference lowered). The rest of this process is ignored in 225 these cases. 227 o The second hop in the AS_PATH attribute is examined. 229 o If the second hop in the AS_PATH is advertised as connected 230 by the originating AS, the Security Preference for this pre- 231 fix SHOULD be increased. 233 o If the second hop in the AS_PATH is not advertised as con- 234 nected by the originating AS, the Security Preference for 235 this prefix SHOULD be decreased. 237 o If the second hop in the AS_PATH is not advertised as con- 238 nected by the originating AS and the originator's policy 239 indicates the second hop MUST be validated, the prefix should 240 be removed from further consideration. 242 o The AS_PATH attribute is compared to the internetwork graph. 244 o If the AS_PATH described is contained within the internetwork 245 graph, the Security Preference SHOULD be increased. 247 o If the AS_PATH described is not contained within the inter- 248 network graph, the Security Preference SHOULD be decreased. 250 o If the AS_PATH traverses a connection which is only described 251 by one of the two autonomous systems, this is a one way con- 252 nection. Local policy may be used to determine if the secu- 253 rity preference should be increased in this case. 255 o If the AS_PATH described is not contained within the inter- 256 network graph, and the originator indicated the AS_PATH MUST 257 be checked, the prefix should be removed from further con- 258 sideration. 260 o The AuthCert chosen at the first step is examined. 262 o If the authorized AS in the AuthCert matches the originating 263 AS in the AS_PATH, the Security Preference SHOULD be 264 increased. 266 o If the authorized AS in the AuthCert does not mathc the ori- 267 ginating AS in the AS_PATH, the Security Preference SHOULD be 268 set low enough to cause the route to be discarded. 270 o Other policies contained in the local authorization database 271 should be applied as directed by the policy. 273 3.4. Validating Received BGP UPDATES 275 As BGP UPDATES are received, they may be processed in one of several 276 ways: 278 o Each prefix may be validated according to the process outlined 279 in Validating Routing Information before they are installed in 280 the ADj-RIB-IN. 282 o Each prefix may be validated according to the process outlined 283 in Validating Routing Information after they are installed in 284 the Adj-RIB-In, but before they are considered in the BGP Best 285 Path calculation. 287 o Each prefix may be validated according to the process outlined 288 in Validating Routing Information after they are run through the 289 Best Path algorithm, but before they are installed in the local 290 RIB. 292 o Routes may be installed in the local RIB, and then validated 293 using the process outlined in Validating Routing Information. 294 Once validation is accomplished, adjustments to the local RIB 295 and routes advertised to BGP peers may need to be adjusted. 297 3.5. Aggregation 299 Aggregation is a difficult problem with any method which attempts to 300 verify the origin of any given prefix, since aggregation removes the 301 relationship between prefixes originated and originators. Prefixes 302 may only be aggregated by an entity which is otherwise authorized to 303 advertise the aggregated prefix. 305 3.6. Requirements for Systems Running soBGP 307 This section describes requirements for autonomous systems running 308 soBGP, requirements for BGP speakers forming external adjacencies 309 from within such autonomous systems, and devices exchanging soBGP 310 certificates. 312 o Any peering session along the border of an autonomous system 313 running soBGP SHOULD be authenticated through some means such as 314 [BGP-MD5], IPsec ([ESP], [AH]), or through some other current, 315 effective means of protecting BGP sessions from being hijacked, 316 or otherwise abused. 318 o Any peering session along which soBGP certificates are exchanged 319 SHOULD be authenticated through some means such as [BGP-MD5], 320 IPsec ([ESP, [AH]), or through some other current, effective 321 means of protecting BGP sessions from being hijacked, or other- 322 wise abused. 324 o The AS_PATH of any routing information received from any BGP 325 peer outside the autonomous system MUST be checked to validate 326 the next hop AS is the AS the update was received from. If the 327 next hop AS in any received update does not match the configured 328 AS the route is learned from, the update MUST be discarded. 330 4. soBGP Deployment 332 This section begins by describing what we believe to be the most 333 practical deployment of this secure registry of routing information. 334 Following sections describe some other deployment options that may 335 prove useful in some situations, or may prove to be more practical 336 than the deployment outlined in this section. 338 4.1. Deploying soBGP on Distributed Registry Servers 340 This deployment scenerio works within three constraints: 342 o It may not be not desirable to combine routing and cryptographic 343 processing of soBGP certificates on the same device. 345 o The system should be distributed, using as few centralized 346 resources as possible. 348 o Trust relationships should be based on existing business and 349 working relationships, rather than building new relationships 350 specifically for securing the routing system. 352 Assume we have a small internetwork, as shown below: 354 S1 - - - - - - - - - - -S2 - - - -S3 356 10.1.1.0/24---A---B-----C---D-----E---F 358 | AS65000 | AS65001 | AS65002 360 In this network, we assume each AS has an soBGP server locally within 361 their AS, marked as S1, S2, and S3, above. These servers are inter- 362 connected in a way similar to eBGP peering between AS65000, AS65001, 363 and AS65002; S1 and S2 are using the mechanisms described in [SOBGP- 364 BGPEXT] to distribute the certificates described in [SOBGP- 365 CERTIFICATE] between them. 367 Each server then processes the certificates as described in [SOBGP- 368 CERTIFICATE], and either provides a set of filters or a mechanism 369 through which the eBGP peering routers can authenticate routing 370 information, such as described in [SOBGP-RADIUS]. This deployment 371 technique provides BGP route validation that is: 373 o Fully Distributed: Local server (or set of servers) which builds 374 the required databases based on received certificates, and dis- 375 tributes certificates throughout the routing system. 377 o Locally Controlled: Each local server (or set of server) is 378 maintained and managed by autonomous systems participating in 379 the internetwork. 381 o Based on Existing Business Relationships: Peering autonomous 382 systems also peer their soBGP servers, so the system uses exist- 383 ing business relationships to provide the deployment and long 384 term maintenance of the system. 386 o Very Little Impact on the Existing Routing System: The current 387 processing and distribution of routing information through [BGP] 388 isn't impacted in any way. The only additional requirements on 389 existing equipment are to compare the routing information to the 390 database results provided by the local servers (i.e., receiving 391 and processing filter lists, or through [SOBGP-RADIUS]). 393 4.2. Certificate Processing on Edge Peering Routers 395 soBGP can also be deployed entirely within BGP speakers at the edge 396 of an Autonomous System (AS). 398 +-(eBGP)-+ +-(eBGP)-+ 399 | | | | 400 v v v V 402 A--------B-----C-----D--------E 403 ^ ^ 404 | | 405 +--(iBGP)---+ 407 In this network, A is sending certificates it has learned from other 408 sources to B using the mechanisms described in [SOBGP-BGPEXT]. It is 409 passing these certificates to D via iBGP, and D is passing these cer- 410 tificates to E via eBGP. Each edge router, B and D, process these 411 certificates locally, building the databases required to validate 412 received routing information from them. 414 4.3. Multihoming Deployment 416 Multihoming presents a special challenge to the deployment of soBGP 417 within a large scale internetwork. 419 (---------) (---------) 420 ( AS65401 ) ( AS65402 ) 421 ( ) ( ) 422 ( ) ( ) 423 (---A---) (---B---) 424 | | 425 \ / 426 \-----+ +-----/ 427 | | 428 (--C------D--) 429 ( ) 430 ( No-AS ) 431 (----------) 433 Assume No-AS has obtained a block of addresses, 10.1.1.0/24, from 434 AS65401, and would like to advertise that same block of addresses 435 through AS65402. Since No-AS has no AS number, it cannot generate any 436 soBGP certificates, and must rely on its upstream providers to work 437 out the security impact in some way. The simplest solution would be, 438 of course, for NOAS to obtain an AS number, and fully participate in 439 soBGP, but barring that, what other solutions are there? 441 AS65401 could issue a certificate allowing AS65402 to originate just 442 the prefix in question, 10.1.1.0/24, or AS65401 could simply list 443 AS65402 in the certificate covering 10.1.1.0/24 as an authorized ori- 444 ginator for this address space (as multiple authorized originators 445 are allowed). 447 4.4. Proxy Advertisement of Certificates 449 Note there is no requirement for a given entity which originates 450 routes into the routing system to actually originate the correspond- 451 ing certificates required for the correct origination of the route to 452 be validated, and the AS Path attached to the route to be verified. 454 (-----------------) 455 ( Other Third Party ) 456 (---------------) 457 / \ 458 / \ 459 (---------) (---------) 460 ( AS65401 ) ( AS65402 ) 461 ( ) ( ) 462 ( ) ( ) 463 (---A---) (---B---) 464 | | 465 \ / 466 \-----+ +-----/ 467 | | 468 (--C------D--) 469 ( ) 470 ( AS65403 ) 471 (----------) 473 In this case, AS65401, AS65402, or some other third part may actually 474 advertise the certificates necessary for AS65403 to originate vali- 475 dated routes. 477 5. Other Deployment Considerations 479 In this section, we move from specific deployment scenerios to other 480 deployment considerations, such as key generation and protection, and 481 memory utilization/impact. 483 5.1. Certificate Generation and Private Key Protection 485 There is only one private/public key pair per autonomous system; cer- 486 tificates are generated as determined by local policy and as required 487 to account for changes in the network. Since the entity's private key 488 is not used in any part of the operations verifying received informa- 489 tion, or in generating information to transmit to other devices, 490 these certificates could be generated on some secure central system 491 in the AS, and the results, containing only public keys, can be 492 transmitted throughout the network. 494 Securing the private key of each entity should be relatively easy in 495 this environment, since the location of the private key can be care- 496 fully constrained; no device other than the system which generates 497 the required certificates needs use of the private key. 499 5.2. Impact on Performance and Memory Utilization 501 Detailed performance and memory utilization characteristics of soBGP 502 will be the subject of future investigation. However, as this is an 503 important area of consideration, we present some suggested analysis 504 below. (In other words, this is a guess). 506 In terms of memory, each device running sobGP will need to store: 508 o Each of the Entitycerts Received. The maximum number of Enti- 509 tycerts within the routing system would be the number partici- 510 pating autonomous systems multiplied by the number of outstand- 511 ing Entitycerts from each autonomous system. 513 o Each of the ASPolicycerts Received. The number of ASPolicycerts 514 within the system will probably be similar to the number of 515 Entitycerts within the system. 517 o Each of the PrefixPolicycerts Received. The number of PrefixPol- 518 icyCerts within the system will depend on the number of address 519 blocks each participant in the routing system advertises, and 520 could double during key rollover. 522 Performance will depend on the cryptographic processing requirements 523 imposed by the certificate signature methods, as described in 524 [SOBGP-CERTIFICATE]. However, all of this additional memory and pro- 525 cessing would most likely be required on a distributed soBGP server, 526 rather than on routers themselves. 528 The primary impact on routers and routing protocol convergence will 529 be the memory and processing requirements added from the additional 530 route filters or processing as required by the deployment technique 531 used. 533 6. Normative References 535 [BGP] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 536 RFC 1771, March 1995. 538 [SOBGP-BGPEXT] 539 Ng J (editor), "Extensions to BGP to Support Secure Origin BGP 540 (soBGP)", draft-ng-sobgp-bgp-extensions-01.txt, April 2004 542 [SOBGP-CERTIFICATE] 543 Weis, Brian (editor), "Secure Origin BGP (soBGP) Certificates", 544 draft-weis-sobgp-certificates-01.txt, October 2003 546 7. Informative References 548 [SOBGP-RADIUS] 549 Lovnick, C, "RADIUS Attributes for soBGP Support", draft-lonvick- 550 sobgp-radius-04.txt, February 2004 552 [PATH-CONSIDER] 553 White, Russ, "Considerations in Validating the Path in Routing Pro- 554 tocols", draft-white-pathconsiderations-02.txt, April 2004 556 [COST] 557 Retana, A., White, R., "BGP Custom Decision Process", draft- 558 retana-bgp-custom-decision-00, October 2002. 560 8. Editor's Address 562 Russ White 563 Cisco Systems 564 7025 Kit Creek Road 565 Research Triangle Park, NC 27709 566 riw@cisco.com