idnits 2.17.1 draft-white-sobgp-architecture-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 963. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 940. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 947. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 953. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 27 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 110: '... certificates MAY be distributed usi...' RFC 2119 keyword, line 166: '...check passes, the connection SHOULD be...' RFC 2119 keyword, line 168: '...ity check fails, the connection MAY be...' RFC 2119 keyword, line 174: '...autonomous system MUST NOT be used for...' RFC 2119 keyword, line 187: '...ng this criteria SHOULD be discarded, ...' (29 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (May 19, 2005) is 6889 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 330, but not defined == Missing Reference: 'GTSH' is mentioned on line 61, but not defined == Missing Reference: 'ESP' is mentioned on line 326, but not defined == Missing Reference: 'AH' is mentioned on line 331, 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-BGPTRANSPORT' == 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 (-02) exists of draft-retana-bgp-custom-decision-00 == Outdated reference: A later version (-09) exists of draft-white-pathconsiderations-02 Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. White 3 Internet-Draft Cisco Systems 4 Expires: November 20, 2005 May 19, 2005 6 Architecture and Deployment Considerations for Secure Origin BGP (soBGP) 7 draft-white-sobgp-architecture-01 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 20, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 There is a great deal of concern over the security of internetworks 41 built using the Border Gateway Protocol to provide routing 42 information to autonomous systems connected to the internetwork. 43 This draft provides an architecture for a secure distributed registry 44 of routing information to address these concerns. The draft begins 45 with an overview of the operation of this system, and then follows 46 with various deployment scenarios, starting with what we believe will 47 be the most common deployment option. 49 1. Motivation 51 2. Overview 53 There are two fundamental pieces of a routing system that need to be 54 secured: 56 o Adjacencies between devices running the routing protocol. 57 o Information carried within the routing protocol. 59 While security between [BGP] speakers has been addressed in a number 60 of ways, including cryptographic authentication [BGP-MD5] and 61 limiting the attack radius through TTL mechanisms [GTSH], security 62 for the information carried within BGP is not considered a solved 63 problem. 65 This draft proposes a possible solution to securing the information 66 within BGP, using the certificates and protocol extensions proposed 67 in [SOBGP-BGPTRANSPORT], [SOBGP-CERTIFICATE], and [SOBGP-RADIUS]. 69 There are three major modifications to this draft since the last 70 edition was published 72 o An additional short section has been added on the impact of soBGP 73 on internetwork convergence. This is a rough cut at an analysis 74 of this work, at this point. 75 o An additional section on incremental deployment, in terms of 76 deploying parts of the soBGP system to solve specific problems. 77 o A section on aggregation considerations has been added. 79 3. General Theory 81 soBGP provides a secure registry mechanism against which a BGP 82 speaker can check: 84 o The authorization of the AS listed as the originating AS in any 85 received update to advertise reachability to the prefix listed in 86 the update. 87 o The validity of the AS Path contained in the update. 89 A valid AS Path, in this document, is a path that has the following 90 attributes: 92 o Each autonomous system listed in the AS Path is an actual 93 participant in the internetwork. 94 o Each pair of autonomous systems listed in the AS Path are actually 95 interconnected. 97 o Starting from the first autonomous system (the origin AS), and 98 passing through each autonomous system listed in the AS Path, 99 actually results in reaching the advertising peer's AS. 101 As shown in [PATH-CONSIDER], it isn't possible to verify an AS more 102 than one AS hop away has authorized the advertisement of specific 103 reachability information based on the AS Path. The concept of 104 policy, and soBGP's interaction with policy, is considered more fully 105 in a later section in this draft. 107 soBGP operates by distributing a set of signed certificates, 108 described in [SOBGP-CERTIFICATE], containing the information required 109 to validate the two pieces of information given above. These 110 certificates MAY be distributed using the mechanisms described in 111 [SOBGP-BGPTRANSPORT], or some other mechanism. Once these 112 certificates have been received and processed (signatures validated, 113 etc, as described in [SOBGP-CERTIFICATE], they form a database 114 containing: 116 o A listing of IP address blocks and the AS authorized to originate 117 them. 118 o Policies related to specific prefixes and blocks of addresses. 119 o A list of autonomous systems connected to each autonomous system 120 within the internetwork. This connection list is used to build a 121 graph of AS interconnectivity within the internetwork, as 122 described in the section Building the AS Connectivity Graph, 123 below. 125 This effectively forms a secure registry of routing information which 126 can be used to check the validity of routing information received 127 from BGP peers. This database is termed the "authorization 128 database." No assumption about the location of the authorization 129 database is made within this document. 131 As BGP updates are processed, a security preference is assigned to 132 each prefix, as described further in the Security Preference section 133 of this document. BGP update processing is described in the 134 Receiving and Processing Updates section of this document. 136 4. soBGP Operation 138 Each section below provides detailed information on some aspect of 139 soBGP operation. 141 4.1 Building the AS Connectivity Graph 143 Each ASPolicycert advertised by a member of the internetwork contains 144 a list of the autonomous systems the advertising AS is connected to, 145 along with possible policy information about that connection. From 146 this information, a graph of AS connectivity within the internetwork 147 is built. 149 Any AS can be used as the starting point for building this graph, 150 thus multiple disconnected graphs (representing section of the 151 internetwork running soBGP and providing interconnection information) 152 are possible. If every AS within the internetwork is providing 153 interconnection information, one graph can be built containing all 154 the internetwork's interconnections. 156 The process of creating this graph is: 158 o Begin with the local AS, or any AS for which an ASPolicycert is 159 available. 160 o Examine the list of connected autonomous systems advertised by the 161 current AS. 162 o Examine the ASPolicycert of each AS the current AS is advertising 163 as connected, and determine if that AS is advertising a connection 164 back to the current AS. This is termed the two way connectivity 165 check. 166 o If the two way connectivity check passes, the connection SHOULD be 167 added to the interconnection graph, and marked as trustable. 168 o If the two way connectivity check fails, the connection MAY be 169 added to the interconnection graph, but marked so a lower security 170 preference will be assigned to routes containing this AS pair in 171 their AS Path. 172 o Apply any policies indicated by either of the two autonomous 173 systems in their ASPolicycert. This could include, for instance, 174 noting the connected autonomous system MUST NOT be used for 175 transiting traffic. 176 o Repeat this process for each ASPolicycert in the authorization 177 database. 179 The resulting graph is called the internetwork graph. 181 4.2 Validating Routing Information (The Security Preference) 183 soBGP provides a two tier evaluation of routes. In the first stage, 184 a BGP speaker evaluating received routing information would discard 185 all routing information found to be false, or not accurately 186 representing the internetwork as it exists. Routing information not 187 meeting this criteria SHOULD be discarded, as indicated in the 188 processing steps outlined below. 190 In the second tier, the BGP speaker assigns a Security Preference to 191 the received routing information, indicating a locally significant 192 trust level determined by examining the received routing information. 194 The amount by which the Security Preference is increased or decreased 195 for any operation described in this draft is locally significant to 196 the autonomous system. This allows the operator provide a finer 197 granularity of security policy, from dropping routing information 198 deemed invalid through simply preferring routes the operator deems 199 "more secure." 201 The operator MAY configure a lower bound. Routes with Security 202 Preferences under this lower bound SHOULD be discarded. Any of the 203 following methods may be used to implement the Security Preference 204 within an autonomous system: 206 o Assign the value of the Security Preference to any of the 207 attributes used in the [BGP] decision process. Care must be taken 208 with attributes for which the lower value is preferred. 209 o Use a Cost Community [COST] and its associated methods to consider 210 the Security Preference at any step in the Decision Process [BGP] 211 without overloading other attributes. Care must be taken as the 212 lowest value in a Cost Community is preferred. 214 Several basic rules apply to all BGP speakers either evaluating the 215 security level of received routing information, or using the Security 216 Preference to determine which path to install in the local RIB: 218 o The method selected to implement the Security Preference MUST be 219 consistent through the local autonomous system. 220 o All devices processing routes against soBGP information MUST use 221 the same mechanisms and values of the Security Preference to 222 ensure consistent routing within the autonomous system. 223 o The Security Preference value may be used to select among 224 different routes for the same prefix; the higher value MUST be 225 preferred. 227 The process described below does not rule out additional policies 228 added locally, or in some future draft. For each route (prefix/ 229 attribute pair) within a given BGP UPDATE message: 231 o The local authorization database is examined, and the Authcert 232 with the longest prefix length encompassing the range of addresses 233 described by the prefix is chosen. 234 o If there is no entry in the local authorization database which 235 encompasses the range of addresses described by the prefix, then 236 the route is said to be unverified. The Security Preference 237 SHOULD be set to a level indicated by local policy. 238 o If there is an AS_SET in the AS_PATH, the following process MAY be 239 followed: 241 * For each AS in the AS_SET, examine the set of PrefixPolicycerts 242 advertised by that AS. 243 * If a PrefixPolicycert is found authorizing at least one of the 244 autonomous systems in the AS_SET to advertise some component of 245 the prefix, the Security Preference MAY be increased or left at 246 its current value. 247 * If a PrefixPolicycert is not found authorizing at least one of 248 the autonomous systems in the AS_SET to advertise some 249 component of the prefix, the Security Preference MAY be 250 decreased or left at its current value. 251 * If a path exists from the aggregator to each AS listed in the 252 AS_SET, the Security Preference MAY be increased or left at its 253 current value. 254 * If a path does not exist from the aggregator to each AS listed 255 in the AS_SET, the Security Preference MAY be decreased or left 256 at its current value. 257 o If there is an AS_SET in the AS_PATH, it is disregarded in all 258 further processing. The originator of the AS is considered the 259 originator of the route. 260 o The second hop in the AS_PATH attribute is examined. 261 o 262 * If the second hop in the AS_PATH is advertised as connected by 263 the originating AS, the Security Preference for this prefix 264 SHOULD be increased. 265 * If the second hop in the AS_PATH is not advertised as connected 266 by the originating AS, the Security Preference for this prefix 267 SHOULD be decreased. 268 * If the second hop in the AS_PATH is not advertised as connected 269 by the originating AS and the originator's policy indicates the 270 second hop MUST be validated, the prefix SHOULD be removed from 271 further consideration. 272 o The AS_PATH attribute is compared to the internetwork graph. 273 o 274 * If a series of two way verified pairwise peerings exists, 275 beginning with the first AS listed in the AS_PATH, and ending 276 in the advertising AS, the Security Preference SHOULD be 277 increased. 278 * If a series of pairwise peerings exists, beginning with the 279 first AS listed in the AS_PATH, and ending in the advertising 280 AS, the Security Preference MAY be increased. This case allows 281 for the inclusion of one-way advertised AS interconnections in 282 the graph. 283 * If the AS_PATH described is not contained within the 284 internetwork graph, and the originator indicated the AS_PATH 285 MUST be checked, the prefix SHOULD be removed from further 286 consideration. 288 * Otherwise, the Security Preference SHOULD be decreased. 289 o The Authcert chosen at the first step is examined. 290 o 291 * If the authorized AS in the Authcert matches the originating AS 292 in the AS_PATH, the Security Preference SHOULD be increased. 293 * If the authorized AS in the Authcert does not match the 294 originating AS in the AS_PATH, the prefix SHOULD be removed 295 from further consideration. 297 4.3 Validating Received BGP UPDATES 299 As BGP UPDATES are received, they MAY be processed at one of several 300 points: 302 o Each prefix may be validated according to the process outlined in 303 Validating Routing Information before they are installed in the 304 ADJ-RIB-IN. 305 o Each prefix may be validated according to the process outlined in 306 Validating Routing Information after they are installed in the 307 ADJ-RIB-IN, but before they are considered in the BGP Best Path 308 calculation. 309 o Each prefix may be validated according to the process outlined in 310 Validating Routing Information after they are run through the Best 311 Path algorithm, but before they are installed in the local RIB. 312 o Routes may be installed in the local RIB, and then validated using 313 the process outlined in Validating Routing Information. Once 314 validation is accomplished, adjustments to the local RIB and 315 routes advertised to BGP peers may need to be adjusted. 317 4.4 Requirements for Systems Running soBGP 319 This section describes requirements for autonomous systems running 320 soBGP, requirements for BGP speakers forming external adjacencies 321 from within such autonomous systems, and devices exchanging soBGP 322 certificates. 324 o Any peering session along the border of an autonomous system 325 running soBGP SHOULD be authenticated through some means such as 326 [BGP-MD5], IPsec ([ESP], [AH]), or through some other current, 327 effective means of protecting BGP sessions from being hijacked, or 328 otherwise abused. 329 o Any peering session along which soBGP certificates are exchanged 330 SHOULD be authenticated through some means such as [BGP-MD5], 331 IPsec ([ESP, [AH]), or through some other current, effective means 332 of protecting BGP sessions from being hijacked, or otherwise 333 abused. 335 o For each received route, the last (most recently added) autonomous 336 system MUST be compared to the autonomous system of the BGP 337 speaker advertising the route. If the last (most recently added) 338 AS in the AS Path does not match the autonomous system of the 339 transmitting speaker, the route MUST be discarded. 341 When soBGP is supported, a BGP speaker MUST have access to the 342 authorization database. Possible methods of access include: 344 o Have a local copy of this authorization database, and perform the 345 checks described later in this document against that local 346 database. 347 o Pass received routing information to a locally maintained server 348 for validation against that server's copy of the authorization 349 database [SOBGP-RADIUS]. 350 o Accept filters built from a copy of the authorization database 351 contained on a locally maintained server. 353 5. soBGP Deployment 355 This section begins by describing what we believe to be the most 356 practical deployment of this secure registry of routing information. 357 Following sections describe some other deployment options that may 358 prove useful in some situations, or may prove to be more practical 359 than the deployment outlined in this section. 361 5.1 Deploying soBGP on Distributed Registry Servers 363 This deployment scenario works within three constraints: 365 o It may not be not desirable to combine routing and cryptographic 366 processing of soBGP certificates on the same device. 367 o The system should be distributed, using as few centralized 368 resources as possible. 369 o Trust relationships should be based on existing business and 370 working relationships, rather than building new relationships 371 specifically for securing the routing system. 373 Assume we have a small internetwork, as shown below: 374 S1 - - - - - - - - - - -S2 - - - -S3 375 10.1.1.0/24---A---B-----C---D-----E---F 376 | AS65000 | AS65001 | AS65002 378 In this network, we assume each AS has an soBGP server locally within 379 their AS, marked as S1, S2, and S3, above. These servers are 380 interconnected in a way similar to eBGP peering between AS65000, 381 AS65001, and AS65002; S1 and S2 are using the mechanisms described in 382 [SOBGP-BGPTRANSPORT] to distribute the certificates described in 384 [SOBGP-CERTIFICATE] between them. 386 Each server then processes the certificates as described in [SOBGP- 387 CERTIFICATE], and either provides a set of filters or a mechanism 388 through which the eBGP peering routers can authenticate routing 389 information, such as described in [SOBGP-RADIUS]. This deployment 390 technique provides BGP route validation that is: 392 o Fully Distributed: Local server (or set of servers) which builds 393 the required databases based on received certificates, and 394 distributes certificates throughout the routing system. 395 o Locally Controlled: Each local server (or set of server) is 396 maintained and managed by autonomous systems participating in the 397 internetwork. 398 o Based on Existing Business Relationships: Peering autonomous 399 systems also peer their soBGP servers, so the system uses existing 400 business relationships to provide the deployment and long term 401 maintenance of the system. 402 o Very Little Impact on the Existing Routing System: The current 403 processing and distribution of routing information through [BGP] 404 isn't impacted in any way. The only additional requirements on 405 existing equipment are to compare the routing information to the 406 database results provided by the local servers (i.e., receiving 407 and processing filter lists, or through [SOBGP-RADIUS]). 409 5.2 Certificate Processing on Edge Peering Routers 411 soBGP can also be deployed entirely within BGP speakers at the edge 412 of an Autonomous System (AS). 414 +-(eBGP)-+ +-(eBGP)-+ 415 | | | | 416 v v v V 418 A--------B-----C-----D--------E 420 ^ ^ 421 | | 422 +--(iBGP)---+ 424 In this network, A is sending certificates it has learned from other 425 sources to B using the mechanisms described in [SOBGP-BGPTRANSPORT]. 426 B is passing these certificates to D via iBGP, and D is passing these 427 certificates to E via eBGP. Each edge router, B and D, process these 428 certificates locally, building the databases required to validate 429 received routing information from them. 431 5.3 Multihoming Deployment 433 Multihoming presents a special challenge to the deployment of soBGP 434 within a large scale internetwork. 436 (---------) (---------) 437 ( AS65401 ) ( AS65402 ) 438 ( ) ( ) 439 ( ) ( ) 440 (---A---) (---B---) 441 | | 442 \ / 443 \-----+ +-----/ 444 | | 445 (--C------D--) 446 ( ) 447 ( No-AS ) 448 (----------) 450 Assume No-AS has obtained a block of addresses, 10.1.1.0/24, from 451 AS65401, and would like to advertise that same block of addresses 452 through AS65402. Since No-AS has no AS number, it cannot generate 453 any soBGP certificates, and must rely on its upstream providers to 454 work out the security impact in some way. The simplest solution 455 would be, of course, for NOAS to obtain an AS number, and fully 456 participate in soBGP, but barring that, what other solutions are 457 there? 459 AS65401 could issue a certificate allowing AS65402 to originate just 460 the prefix in question, 10.1.1.0/24, or AS65401 could simply list 461 AS65402 in the certificate covering 10.1.1.0/24 as an authorized 462 originator for this address space (as multiple authorized originators 463 are allowed). 465 5.4 Proxy Advertisement of Certificates 467 Note there is no requirement for a given entity which originates 468 routes into the routing system to actually originate the 469 corresponding certificates required for the correct origination of 470 the route to be validated, and the AS Path attached to the route to 471 be verified. 473 (-----------------) 474 ( Other Third Party ) 475 (---------------) 476 / \ 477 / \ 478 (---------) (---------) 479 ( AS65401 ) ( AS65402 ) 480 ( ) ( ) 481 ( ) ( ) 482 (---A---) (---B---) 483 | | 484 \ / 485 \-----+ +-----/ 486 | | 487 (--C------D--) 488 ( ) 489 ( AS65403 ) 490 (----------) 492 In this case, AS65401, AS65402, or some other third part may actually 493 advertise the certificates necessary for AS65403 to originate 494 validated routes. 496 6. Other Considerations 498 In this section, we move from specific deployment scenarios to other 499 deployment considerations, such as key generation and protection, and 500 memory utilization/impact. 502 6.1 Certificate Generation and Private Key Protection 504 There is only one private/public key pair per autonomous system; 505 certificates are generated as determined by local policy and as 506 required to account for changes in the network. Since the entity's 507 private key is not used in any part of the operations verifying 508 received information, or in generating information to transmit to 509 other devices, these certificates could be generated on some secure 510 central system in the AS, and the results, containing only public 511 keys, can be transmitted throughout the network. 513 Securing the private key of each entity should be relatively easy in 514 this environment, since the location of the private key can be 515 carefully constrained; no device other than the system which 516 generates the required certificates needs use of the private key. 518 6.2 Impact on Performance and Memory Utilization 520 Detailed performance and memory utilization characteristics of soBGP 521 will be the subject of future investigation. However, as this is an 522 important area of consideration, we present some suggested analysis 523 below. (In other words, this is a guess). 525 In terms of memory, each device running soBGP will need to store: 527 o Each of the Entitycerts Received. The maximum number of 528 Entitycerts within the routing system would be the number 529 participating autonomous systems multiplied by the number of 530 outstanding Entitycerts from each autonomous system. 531 o Each of the ASPolicycerts Received. The number of ASPolicycerts 532 within the system will probably be similar to the number of 533 Entitycerts within the system. 534 o Each of the PrefixPolicycerts Received. The number of 535 PrefixPolicycerts within the system will depend on the number of 536 address blocks each participant in the routing system advertises, 537 and could double during key rollover. 539 Performance will depend on the cryptographic processing requirements 540 imposed by the certificate signature methods, as described in [SOBGP- 541 CERTIFICATE]. However, all of this additional memory and processing 542 would most likely be required on a distributed soBGP server, rather 543 than on routers themselves. 545 The primary impact on routers and routing protocol convergence will 546 be the memory and processing requirements added from the additional 547 route filters or processing as required by the deployment technique 548 used. 550 6.3 soBGP Impact on Internetwork Convergence 552 We generally assume that adding a security infrastructure on top of 553 an operating system will dramatically decrease the performance of 554 that system. However, much depends on the system being modified, 555 itself, and how closely to perfectly efficient that system already 556 performs. We've already examined, in prior sections, the impact of 557 soBGP on memory and processor utilization in devices running these 558 extensions, but we've not examined the impact of soBGP on another 559 aspect of an internetwork's operation, convergence time. In this 560 section, we will examine some possible side effects of deploying 561 soBGP using the following small internetwork as an example. 562 +--B--C--D--+ 563 | | 564 A---E---F---G---K 565 | | 566 +-----H-----+ 568 In this network, assume that: 570 o A prefers the path through {H,G} to K. 571 o E prefers the path through {F,G} to K. 572 o B prefers the path through {C,D,G} to K. 574 In this network, if the link from G to K fails: 576 o A will first receive a withdraw from H, and begin to prefer the 577 path through {E,F,G} to K. 578 o A will then receive a withdraw from E, and begin to prefer the 579 path through {C,D,E,G} to K. 580 o A will finally receive a withdraw from C, and remove the route to 581 K from its local tables. 583 This processing pattern is well documented through multiple studies 584 in the operations of [BGP] in large scale internetworks. The most 585 obvious answer to resolve this problem is for G to include some sort 586 of information in its withdraw indicating the nature of the failure, 587 so A can directly remove all paths through the link {G,K} on 588 receiving the first withdraw. This is more problematic than it 589 appears, however, because [BGP] is designed for protocol efficiency, 590 and withdraws are often removed from the internetwork, along with any 591 information they might contain, at an early point in the convergence 592 process. 594 The mechanism soBGP uses to build a graph of the interconnections 595 between the autonomous systems in the internetwork, however, provide 596 another place where this sort of direct information about changes in 597 the topology of the internetwork can be distributed. If this network 598 were running soBGP, G would be able to reissue its certificate 599 claiming connectivity to K, or use some specific policy indicator to 600 note the link {G,K} has failed. On receiving this certificate, all 601 the autonomous systems could remove all routes with the link {G,K} in 602 their AS Paths, and the network would converge with much less 603 distribution and processing of routing information. 605 We believe there are probably several performance enhancements that 606 may be gained through the laying of a connectivity graph on top of 607 the current [BGP] provided view of an internetwork. These types of 608 efficiency gains may overcome or fully offset the added costs of 609 deploying soBGP as a security system. 611 6.4 Aggregation 613 Aggregation is a diificult problem within any system attempting to 614 validate routes in an internetwork running BGP. The primary purpose 615 of aggregation is to remove information from the routing system, and 616 information removed from the system cannot be validated or verified. 617 This appears to be a simple observation, but it has a number of far 618 reaching impacts. 620 ( AS1 ) (AS4) (AS5) 621 10.1.0.0/24----A-----+ 622 | 623 ( AS2 ) | (AS5) 624 10.1.1.0/24----------B----C 625 | 626 ( AS3 ) | 627 10.1.2.0/24----------+ 629 In this small internetwork, B is aggregating 10.1.0.0/24, 630 10.1.1.0/24, and 10.1.2.0/24, into a single advertisement, 631 10.1.0.0/22, towards C, using the mechanism described in [BGP]. C 632 receives 10.1.0.0/22 with the combined communities of 10.1.0.0/24, 633 10.1.1.0/24, and 10.1.2.0/24, and an AS Path of {(1,2,3,4),5}. What 634 information can C learn from this advertisement? 636 o 10.1.0.0/22 is an aggregate, and AS5 claims it has learned some 637 component of 10.1.0.0/22 through or from AS1, AS2, AS3, or AS4. 638 o AS5 claims to be able to reach AS1, AS2, AS3, and AS4. 639 o AS5 claims it can reach any existing destination within 640 10.1.0.0/22, given no other longer prefix route to a component of 641 this address space exists. 642 o AS5 is authorized to advertise 10.1.0.0/22. 643 Can C validate any of these pieces of information? 645 6.4.1 The Route is an Aggregate 647 C assumes 10.1.0.0/22 is an aggregate because of the AS Set contained 648 in the AS Path; is there any way to validate this claim? If C has 649 the PrefixPolicycerts for 10.1.0.0/24, 10.1.1.0/24, and 10.1.2.0/24, 650 it would be able to determine that some of the components of 651 10.1.0.0/22 are, in fact, owned by at least some of the autonomous 652 systems listed in the AS Set. This ability, however, is dependant on 653 C having at least one PrefixPolicycert from AS1, AS2, or AS3, which 654 depends on all certificates being flooded throughout the 655 internetwork, regardless of the flow of routing information. If 656 certificates are blocked when route aggregation or filtering is 657 performed at B, C will not have these certificates. 659 Therefore, we can prove a route is actually an aggregate, if we have 660 at least one PrefixPolicycert from one of the autonomous systems 661 listed in the AS Set, and that PrefixPolicycert contains at least 662 some component of the advertised aggregate. C cannot, however, 663 definitively prove the route is not an aggregate, because it cannot 664 know if it simply does not have such a certificate, or if the 665 aggregate isn't really an aggregate. 667 If it is the policy of the internetwork in which soBGP is deployed to 668 require all certificates to be flooded to all autonomous systems, 669 soBGP MAY use this test to verify a route is actually an aggregate. 671 6.4.2 Reachability to the Members of the AS Set 673 If C has the ASPolicycerts of AS1, AS2, AS3, AS4, and AS5, its local 674 connectivity graph of the internetwork is going to include these 675 autonomous systems. In this case, C could verify AS5 can reach each 676 of the autonomous systems included in the AS Set. Note, however, that 677 in highly meshed internetworks, reachability will exist between 678 almost every pair of nodes through multiple paths, so C cannot prove 679 AS5 should be advertising the received aggregate along this link, or 680 peering session. 682 If it is the policy of the internetwork in which soBGP is deployedto 683 require all certificates to be flooded to all autonomous systems, 684 soBGP MAY use this test to verify connectivity between an aggregator 685 and the autonomous systems listed in the AS_SET of a received 686 aggregate. 688 6.4.3 Reachability to All Destinations Within the Aggregate 690 Can C prove AS5 is able to reach every possible destination with 691 10.1.0.0/22? Assume C has PrefixPolicycerts from AS1, AS2, AS3, AS4, 692 and AS5. From these PrefixPolicycerts, C could determine AS5 could 693 be receiving at least three components of 10.1.0.0/22: 10.1.0.0/24, 694 10.1.1.0/24, and 10.1.2.0/24. However, there is no way to verify AS5 695 is actually receiving these components. For instance: 696 o While AS1 may be authorized to advertise 10.1.0.0/24, and may 697 normally advertise 10.1.0.0/24 to AS4, the AS1 to AS4 link may be 698 failed, and therefore AS5 may not be receiving this component. 699 o AS1 may be authorized to advertise 10.1.3.0/24, but may not have 700 any hosts reachable in that range of addresses, and therefore 701 might not be advertising it. 702 In other words, AS5 may not be receiving components of a given 703 aggregate route because the component doesn't exist, or is not 704 reachable through AS5. Neither of these conditions can be verified 705 by C, so AS5's reachability to all the destinations listed within an 706 aggregate cannot be verified. 708 6.4.4 Authorization to Advertise an Aggregate 710 There are at least two ways authorization to advertise an aggregate 711 could be defined: 713 o The advertising autonomous system is known to have reachability to 714 all the components contained within the aggregate, and is 715 authorized to aggregate the address space by each of the owners of 716 those components. 717 o The advertising autonomous system is authorized to directly 718 advertise the address space indicated in the aggregate route. 719 The first definition fails on two counts: 720 o There is no way to prove an aggregating autonomous system has 721 reachability to every possible component of an advertised 722 aggregate. 723 o Given the receiver of an aggregate does not know what the complete 724 list of reachable components within an aggregate actually is, 725 there is no way for the receiver of an aggregate to know if all 726 the component's owners have actually authorized the aggregator to 727 advertise the aggregate. 729 This leads to the conclusion that authorization to advertise an 730 aggregate can only exist in the second sense; that if an autonomous 731 system has authorization to advertise the address block (because it 732 has a AuthCert authorizing the advertisement of the address block), 733 then the autonomous system is authorized to advertize the aggregate. 735 7. Incremental Deployment of soBGP 737 One of the primary concerns with any security system is the ability 738 of users to incrementally deploy the system without impacting current 739 network operations. As the security system is deployed, it should 740 provide greater security. In theory, the amount of additional 741 security offered verses the additional work required should be fairly 742 balanced. 744 There are two aspects of incremental deployment that need to be 745 considered: 747 o The impact of some of the participants in the system deploying the 748 security system, but not all participants deploy the system. 749 o The impact of some part of the system being deployed widely, but 750 not all of the system. 752 7.1 Not All Connected Networks Participate 754 The first consideration in incremental deployment of soBGP is asking 755 what happens if all of the autonomous systems in an internetwork 756 don't run soBGP. Is there any advantage to partial deployments of 757 soBGP in this sense? 759 Throughout this section, we will assume soBGP certificates are 760 received by all autonomous systems running soBGP, even if they are 761 separated by multiple hops which are not running soBGP. This is not 762 an unreasonable assumption, since soBGP certificates can be shared in 763 multiple ways, including multihop BGP sessions across non- 764 participating autonomous systems. 766 Assume we have the following small internetwork, what impact will 767 incrementally deploying soBGP through this network have? 768 (AS1) (AS2) (AS3) (AS4 ) 769 A-----B-----C-----D---10.1.1.0/24 771 Assume AS3 and AS4 deploy soBGP, but not AS1 and AS2; is there any 772 value? When AS3 receives routes from AS4, it can verify AS4 is 773 authorized to advertise 10.1.1.0/24. Further, any routes AS3 774 forwards to AS4 from AS1 or AS2 can be validated, to some degree, by 775 AS4. The AS Path can be checked to make certain AS2 is actually 776 connected to AS3 (since AS3 is advertising its connectivity to AS3). 777 If some route is advertised from AS2 showing an AS hop in the middle 778 of those two autonomous systems, it can be safely discarded by AS4 as 779 an invalid AS Path. 781 We can make an alternate assumption, that AS1 and AS4 have deployed 782 soBGP, while AS2 and AS3 have not. In this case, what gains would be 783 made by deploying soBGP? Assume Router A receives a route from 784 Router B with an AS Path of {B,C,D}. If Router A has access to 785 Router D's certificates, it can: 787 o Check the origin AS (the first AS in the AS Path, in this case 788 AS4) is authorized to advertise the address space (in this case 789 10.1.1.0/24). 790 o Check the second hop in the AS Path (in this case AS3) is actually 791 attached to AS4, as advertised by AS4. 792 o Since Router A knows it is connected to AS2, through B, it can 793 also validate the last AS listed in the AS Path. 795 There is some gain, then, in deploying soBGP in both of these 796 situations. The gain is obviously more in the second scenario than 797 the first. 799 7.2 Deploying Parts of soBGP 801 The second question concerning incremental deploying is if 802 implementing some part of soBGP, without the remainder, would be 803 useful. This question is generally placed in the context of 804 validating the origination authorization of routes, and possibly the 805 first hop in the AS Path, but not the entire AS Path. 807 o soBGP Authcerts could be advertised or published (for instance, on 808 a Web page), to provide authorization for each origin AS to 809 advertise specific address blocks. These certificates could be 810 self signed, in the most relaxed case, or signed by the entity 811 authorizing the AS to advertise the address block. 812 o soBGP PrefixPolicycerts could be advertised or published (for 813 instance, on a web page), to provide authorization and first hop 814 checking for received routes. The Authcert within the 815 PrefixPolicycert contains the information required to validate the 816 origin's authorization to originate a route. The list of MAY 817 TRANSIT autonomous systems contained in the PrefixPolicycert would 818 provide the ability to check the first hop in the AS Path of any 819 received route. 820 o soBGP PrefixPolicycerts and ASPolicycerts could be advertised to 821 provide authorization to advertise a route from within an address 822 block, and also provide the ability to validate the first hop in 823 the AS Path. The Authcert, within the PrefixPolicycert, contains 824 the information required to validate the origin's authorization to 825 originate a route. The list of connected autonomous systems 826 within the ASPolicycert provides the information required to 827 validate the first hop in the AS Path of any received route. 829 Any of these modes of operation could be mixed with a full deployment 830 of soBGP, and provides checks for the first hop and origination of 831 received routes. 833 8. Policy Interactions with soBGP 835 Beyond simply securing the information contained within the routing 836 database [BGP] builds, it's also desirable to have a secure mechanism 837 for an autonomous system to advertise policy information. For 838 instance, an autonomous system may not want a specific peer to 839 transit traffic, or an originator may want routing information to be 840 advertised only to a specific number of AS hops away from the origin. 842 The sections below examine some various policies of this type, and 843 possible solutions within soBGP. 845 8.1 Indicating Do Not Transit 847 In the following small internetwork, A would like to enforce a policy 848 preventing C from transiting traffic from B to A. 850 A-------B--------D 851 | | 852 +---C---+ 854 A may attempt to prevent C from transiting traffic from B to A by 855 advertising its routing information to C in such a way that C cannot 856 readvertise that routing information to B. The problem with this 857 approach is that B must assume the lack of specific routing 858 information from C indicates A has a local policy forbidding C from 859 transiting traffic to A. Unfortunately, because of the nature of 860 address space assignment, aggregation, filtering, and other factors, 861 B cannot make this assumption. For instance, C may receive a 862 superset of the routing information A is advertising, and advertise 863 those routes to B instead, in which case A will find there's no 864 effective way to enforce its policy towards C. 866 We find, however, that the interconnection graph laid on top of the 867 routing information transmitted by each autonomous system provides a 868 point where A may communicate its nontransit policy towards C 869 directly to B. Using its ASPolicycert, A may indicate B is not a 870 transit AS, allowing B to mark routes with the AS pair {B,A} in their 871 AS Path with a lower security preference, or possibly even discarding 872 such routing information altogether. 874 This is a simple application of the policies available in the soBGP 875 certificates; more complex policies may be expressed through similar 876 means. The certificates described in [SOBGP-CERTIFICATE] are built 877 so policies may be added in the future, as well. 879 9. Acknowledgements 881 A large number of people contributed to this draft either by 882 contributing text, ideas, or comments; we've tried to include all of 883 them here (but might have missed a few): James Ng, Tim Gage, Alvaro 884 Retana, Dave Cook, Brian Weis, Iljitsch van Beijnum, Bora Akyol, Tony 885 Li, and Sue Hares. 887 10. Security Considerations 889 11. IANA Considerations 891 12. References 893 12.1 Normative References 895 [BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 896 (BGP-4)", RFC 1771, March 1995. 898 [SOBGP-BGPTRANSPORT] 899 Ng, J., "Extensions to BGP Transport soBGP certificates", 900 draft-ng-sobgp-bgp-extensions-01.txt (work in progress), 901 April 2004. 903 [SOBGP-CERTIFICATE] 904 Weiss, B., "Secure Origin BGP (soBGP) certificates", 905 draft-weis-sobgp-certificates-01.txt (work in progress), 906 October 2003. 908 12.2 Informative References 910 [COST] Retana, A. and R. White, "BGP Custom Decision Process", 911 draft-retana-bgp-custom-decision-00.txt (work in 912 progress), October 2002. 914 [PATH-CONSIDER] 915 White, R., "Considerations in Validating the Path in 916 Routing Protocols", draft-white-pathconsiderations-02.txt 917 (work in progress), April 2004. 919 [SOBGP-RADIUS] 920 Lonvick, C., "RADIUS Attributes for soBGP Support", 921 draft-lonvick-sobgp-radius-04.txt (work in progress), 922 February 2004. 924 Author's Address 926 Russ White, editor 927 Cisco Systems 929 Email: riw@cisco.com 931 Intellectual Property Statement 933 The IETF takes no position regarding the validity or scope of any 934 Intellectual Property Rights or other rights that might be claimed to 935 pertain to the implementation or use of the technology described in 936 this document or the extent to which any license under such rights 937 might or might not be available; nor does it represent that it has 938 made any independent effort to identify any such rights. Information 939 on the procedures with respect to rights in RFC documents can be 940 found in BCP 78 and BCP 79. 942 Copies of IPR disclosures made to the IETF Secretariat and any 943 assurances of licenses to be made available, or the result of an 944 attempt made to obtain a general license or permission for the use of 945 such proprietary rights by implementers or users of this 946 specification can be obtained from the IETF on-line IPR repository at 947 http://www.ietf.org/ipr. 949 The IETF invites any interested party to bring to its attention any 950 copyrights, patents or patent applications, or other proprietary 951 rights that may cover technology that may be required to implement 952 this standard. Please address the information to the IETF at 953 ietf-ipr@ietf.org. 955 Disclaimer of Validity 957 This document and the information contained herein are provided on an 958 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 959 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 960 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 961 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 962 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 963 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 965 Copyright Statement 967 Copyright (C) The Internet Society (2005). This document is subject 968 to the rights, licenses and restrictions contained in BCP 78, and 969 except as set forth therein, the authors retain all their rights. 971 Acknowledgment 973 Funding for the RFC Editor function is currently provided by the 974 Internet Society.