idnits 2.17.1 draft-white-sobgp-architecture-02.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 904. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 881. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 888. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 894. ** 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 14 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 99: '... certificates MAY be distributed usi...' RFC 2119 keyword, line 155: '...check passes, the connection SHOULD be...' RFC 2119 keyword, line 157: '...ity check fails, the connection MAY be...' RFC 2119 keyword, line 163: '...autonomous system MUST NOT be used for...' RFC 2119 keyword, line 176: '...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 (June 15, 2006) is 6496 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 311, but not defined == Missing Reference: 'GTSH' is mentioned on line 61, but not defined == Missing Reference: 'ESP' is mentioned on line 311, but not defined == Missing Reference: 'AH' is mentioned on line 316, but not defined == Missing Reference: 'SOBGP-TRANSPORT' is mentioned on line 384, but not defined == Missing Reference: 'RFC3779' is mentioned on line 481, but not defined ** Obsolete normative reference: RFC 1771 (ref. 'BGP') (Obsoleted by RFC 4271) == 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 == Outdated reference: A later version (-02) exists of draft-ng-sobgp-bgp-extensions-01 Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 8 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: December 17, 2006 June 15, 2006 6 Architecture and Deployment Considerations for Secure Origin BGP (soBGP) 7 draft-white-sobgp-architecture-02 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 December 17, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 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 3. General Theory 71 soBGP provides a secure registry mechanism against which a BGP 72 speaker can check: 74 o The authorization of the AS listed as the originating AS in any 75 received update to advertise reachability to the prefix listed in 76 the update. 77 o The validity of the AS Path contained in the update. 79 A valid AS Path, in this document, is a path that has the following 80 attributes: 82 o Each autonomous system listed in the AS Path is an actual 83 participant in the internetwork. 84 o Each pair of autonomous systems listed in the AS Path are actually 85 interconnected. 86 o Starting from the first autonomous system (the origin AS), and 87 passing through each autonomous system listed in the AS Path, 88 actually results in reaching the advertising peer's AS. 90 As shown in [PATH-CONSIDER], it isn't possible to verify an AS more 91 than one AS hop away has authorized the advertisement of specific 92 reachability information based on the AS Path. The concept of 93 policy, and soBGP's interaction with policy, is considered more fully 94 in a later section in this draft. 96 soBGP operates by distributing a set of signed certificates, 97 described in [SOBGP-CERTIFICATE], containing the information required 98 to validate the two pieces of information given above. These 99 certificates MAY be distributed using the mechanisms described in 100 [SOBGP-BGPTRANSPORT], or some other mechanism. Once these 101 certificates have been received and processed (signatures validated, 102 etc, as described in [SOBGP-CERTIFICATE], they form a database 103 containing: 105 o A listing of IP address blocks and the AS authorized to originate 106 them. 107 o Policies related to specific prefixes and blocks of addresses. 108 o A list of autonomous systems connected to each autonomous system 109 within the internetwork. This connection list is used to build a 110 graph of AS interconnectivity within the internetwork, as 111 described in the section Building the AS Connectivity Graph, 112 below. 114 This effectively forms a secure registry of routing information which 115 can be used to check the validity of routing information received 116 from BGP peers. This database is termed the "authorization 117 database." No assumption about the location of the authorization 118 database is made within this document. 120 As BGP updates are processed, a security preference is assigned to 121 each prefix, as described further in the Security Preference section 122 of this document. BGP update processing is described in the 123 Receiving and Processing Updates section of this document. 125 4. soBGP Operation 127 Each section below provides detailed information on some aspect of 128 soBGP operation. 130 4.1. Building the AS Connectivity Graph 132 Each ASPolicycert advertised by a member of the internetwork contains 133 a list of the autonomous systems the advertising AS is connected to, 134 along with possible policy information about that connection. From 135 this information, a graph of AS connectivity within the internetwork 136 is built. 138 Any AS can be used as the starting point for building this graph, 139 thus multiple disconnected graphs (representing section of the 140 internetwork running soBGP and providing interconnection information) 141 are possible. If every AS within the internetwork is providing 142 interconnection information, one graph can be built containing all 143 the internetwork's interconnections. 145 The process of creating this graph is: 147 o Begin with the local AS, or any AS for which an ASPolicycert is 148 available. 149 o Examine the list of connected autonomous systems advertised by the 150 current AS. 151 o Examine the ASPolicycert of each AS the current AS is advertising 152 as connected, and determine if that AS is advertising a connection 153 back to the current AS. This is termed the two way connectivity 154 check. 155 o If the two way connectivity check passes, the connection SHOULD be 156 added to the interconnection graph, and marked as trustable. 157 o If the two way connectivity check fails, the connection MAY be 158 added to the interconnection graph, but marked so a lower security 159 preference will be assigned to routes containing this AS pair in 160 their AS Path. 161 o Apply any policies indicated by either of the two autonomous 162 systems in their ASPolicycert. This could include, for instance, 163 noting the connected autonomous system MUST NOT be used for 164 transiting traffic. 165 o Repeat this process for each ASPolicycert in the authorization 166 database. 168 The resulting graph is called the internetwork graph. 170 4.2. Validating Routing Information (The Security Preference) 172 soBGP provides a two tier evaluation of routes. In the first stage, 173 a BGP speaker evaluating received routing information would discard 174 all routing information found to be false, or not accurately 175 representing the internetwork as it exists. Routing information not 176 meeting this criteria SHOULD be discarded, as indicated in the 177 processing steps outlined below. 179 In the second tier, the BGP speaker assigns a Security Preference to 180 the received routing information, indicating a locally significant 181 trust level determined by examining the received routing information. 182 The amount by which the Security Preference is increased or decreased 183 for any operation described in this draft is locally significant to 184 the autonomous system. This allows the operator provide a finer 185 granularity of security policy, from dropping routing information 186 deemed invalid through simply preferring routes the operator deems 187 "more secure." 189 The operator MAY configure a lower bound. Routes with Security 190 Preferences under this lower bound SHOULD be discarded. Any of the 191 following methods may be used to implement the Security Preference 192 within an autonomous system: 194 o Assign the value of the Security Preference to any of the 195 attributes used in the [BGP] decision process. Care must be taken 196 with attributes for which the lower value is preferred. 197 o Use a Cost Community [COST] and its associated methods to consider 198 the Security Preference at any step in the Decision Process [BGP] 199 without overloading other attributes. Care must be taken as the 200 lowest value in a Cost Community is preferred. 202 Several basic rules apply to all BGP speakers either evaluating the 203 security level of received routing information, or using the Security 204 Preference to determine which path to install in the local RIB: 206 o The method selected to implement the Security Preference MUST be 207 consistent through the local autonomous system. 208 o All devices processing routes against soBGP information MUST use 209 the same mechanisms and values of the Security Preference to 210 ensure consistent routing within the autonomous system. 211 o The Security Preference value may be used to select among 212 different routes for the same prefix; the higher value MUST be 213 preferred. 215 The process described below does not rule out additional policies 216 added locally, or in some future draft. For each route (prefix/ 217 attribute pair) within a given BGP UPDATE message: 219 o The local authorization database is examined, and the Authcert 220 with the longest prefix length encompassing the range of addresses 221 described by the prefix is chosen. If there is no entry in the 222 local authorization database which encompasses the range of 223 addresses described by the prefix, then the route is said to be 224 unverified. The Security Preference SHOULD be set to a level 225 indicated by local policy. 226 o If there is an AS_SET in the AS_PATH, the following process MAY be 227 followed for each AS_SET: 228 * For each AS in the AS_SET, examine the set of PrefixPolicycerts 229 advertised by that AS. 230 * If a PrefixPolicycert is found authorizing at least one of the 231 autonomous systems in the AS_SET to advertise some component of 232 the prefix, the Security Preference MAY be increased or left at 233 its current value. 234 * If a PrefixPolicycert is not found authorizing at least one of 235 the autonomous systems in the AS_SET to advertise some 236 component of the prefix, the Security Preference MAY be 237 decreased or left at its current value. 239 * If a path exists from the aggregator to each AS listed in the 240 AS_SET, the Security Preference MAY be increased or left at its 241 current value. 242 * If a path does not exist from the aggregator to each AS listed 243 in the AS_SET, the Security Preference MAY be decreased or left 244 at its current value. 245 o If there is an AS_SET in the AS_PATH, it is disregarded in all 246 further processing. The first AS contained in the AS_PATH not 247 contained in the AS_SET is considered the originator of the route 248 for the remainder of the processing. 249 o The second hop in the AS_PATH attribute is examined. 250 * If the second hop in the AS_PATH is advertised as connected by 251 the originating AS, the Security Preference for this prefix 252 SHOULD be increased. 253 * If the second hop in the AS_PATH is not advertised as connected 254 by the originating AS, the Security Preference for this prefix 255 SHOULD be decreased. 256 * If the second hop in the AS_PATH is not advertised as connected 257 by the originating AS and the originator's policy indicates the 258 second hop MUST be validated, the prefix SHOULD be removed from 259 further consideration. 260 o The AS_PATH attribute is compared to the internetwork graph. 261 * If a series of two way verified pairwise peerings exists, 262 beginning with the first AS listed in the AS_PATH, and ending 263 in the advertising AS, the Security Preference SHOULD be 264 increased. 265 * If a series of pairwise peerings exists, beginning with the 266 first AS listed in the AS_PATH, and ending in the advertising 267 AS, the Security Preference MAY be increased. This case allows 268 for the inclusion of one-way advertised AS interconnections in 269 the graph. 270 * If the AS_PATH described is not contained within the 271 internetwork graph, and the originator indicated the AS_PATH 272 MUST be checked, the prefix SHOULD be removed from further 273 consideration. 274 * Otherwise, the Security Preference SHOULD be decreased. 275 o The Authcert chosen at the first step is examined. 276 * If the authorized AS in the Authcert matches the originating AS 277 in the AS_PATH, the Security Preference SHOULD be increased. 278 * If the authorized AS in the Authcert does not match the 279 originating AS in the AS_PATH, the prefix SHOULD be removed 280 from further consideration. 282 4.3. Validating Received BGP UPDATES 284 As BGP UPDATES are received, they MAY be processed at one of several 285 points: 287 o Each prefix may be validated according to the process outlined in 288 Validating Routing Information before they are installed in the 289 ADJ-RIB-IN. 290 o Each prefix may be validated according to the process outlined in 291 Validating Routing Information after they are installed in the 292 ADJ-RIB-IN, but before they are considered in the BGP Best Path 293 calculation. 294 o Each prefix may be validated according to the process outlined in 295 Validating Routing Information after they are run through the Best 296 Path algorithm, but before they are installed in the local RIB. 297 o Routes may be installed in the local RIB, and then validated using 298 the process outlined in Validating Routing Information. Once 299 validation is accomplished, the local RIB and routes advertised to 300 BGP peers may need to be adjusted. 302 4.4. Requirements for Systems Running soBGP 304 This section describes requirements for autonomous systems running 305 soBGP, requirements for BGP speakers forming external adjacencies 306 from within such autonomous systems, and devices exchanging soBGP 307 certificates. 309 o Any peering session along the border of an autonomous system 310 running soBGP SHOULD be authenticated through some means such as 311 [BGP-MD5], IPsec ([ESP], [AH]), or through some other current, 312 effective means of protecting BGP sessions from being hijacked, or 313 otherwise abused. 314 o Any peering session along which soBGP certificates are exchanged 315 SHOULD be authenticated through some means such as IPsec ([ESP, 316 [AH]), or through some other current, effective means of 317 protecting these sessions from being hijacked, or otherwise 318 abused. 319 o For each received route, the last (most recently added) autonomous 320 system MUST be compared to the autonomous system of the BGP 321 speaker advertising the route. If the last (most recently added) 322 AS in the AS Path does not match the autonomous system of the 323 transmitting speaker, the route MUST be discarded. 325 When soBGP is supported, a BGP speaker MUST have access to the 326 authorization database. Possible methods of access include: 328 o Have a local copy of this authorization database, and perform the 329 checks described later in this document against that local 330 database. 331 o Pass received routing information to a locally maintained server 332 for validation against that server's copy of the authorization 333 database. [SOBGP-RADIUS] describes one such possible access 334 mechanism, although others are possible. 336 o Accept filters built from a copy of the authorization database 337 contained on a locally maintained server. 339 4.5. Logging Requirements 341 Any system valildating received routing information using an soBGP 342 database built using the mechanisms described in this draft SHOULD 343 log: 345 o Any change in the Security Preference of any processed route, and 346 the reason for the change in Security Preference. 347 o Any route that is discarded from further processing, and the 348 reason for the discarding of the route. 349 o Any route that is marked as unverified. 350 o The verification of any certificate received by an soBGP speaker. 351 o Failure to verify any certificate received by an soBGP speaker, 352 and why the certificate failed to be verified. 354 5. soBGP Deployment 356 This section begins by describing what we believe to be the most 357 practical deployment of this secure registry of routing information. 358 Following sections describe some other deployment options that may 359 prove useful in some situations, or may prove to be more practical 360 than the deployment outlined in this section. 362 5.1. Deploying soBGP on Distributed Registry Servers 364 This deployment scenario works within three constraints: 366 o It may not be not desirable to combine routing and cryptographic 367 processing of soBGP certificates on the same device. 368 o The system should be distributed, using as few centralized 369 resources as possible. 370 o Trust relationships should be based on existing business and 371 working relationships, rather than building new relationships 372 specifically for securing the routing system. 374 Assume we have a small internetwork, as shown below: 375 S1 - - - - - - - - - - -S2 - - - -S3 376 10.1.1.0/24---A---B-----C---D-----E---F 377 | AS65000 | AS65001 | AS65002 379 In this network, we assume each AS has an soBGP server locally within 380 their AS, marked as S1, S2, and S3, above. These servers are 381 interconnected to distribute the certificates described in [SOBGP- 382 CERTIFICATE] between them (possibly using the mechanism outlines in 384 [SOBGP-TRANSPORT], but other transport mechanisms are possible). 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: A local server (or a set of servers) builds the 393 required databases based on received certificates, and distributes 394 certificates throughout the routing system. 395 o Locally Controlled: Each local server (or set of servers) 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, through [SOBGP-RADIUS], or through 408 some other mechanism). 410 5.2. Certificate Processing on Edge Peering Routers 412 soBGP can also be deployed entirely within BGP speakers at the edge 413 of an Autonomous System (AS). 415 +-(eBGP)-+ +-(eBGP)-+ 416 | | | | 417 v v v V 419 A--------B-----C-----D--------E 421 ^ ^ 422 | | 423 +--(iBGP)---+ 425 In this network, A is sending certificates it has learned from other 426 sources to B using the mechanisms described in [SOBGP-BGPTRANSPORT]. 427 B is passing these certificates to D via iBGP, and D is passing these 428 certificates to E via eBGP. Each edge router, B and D, process these 429 certificates locally, building the databases required to validate 430 received routing information from them. 432 B has two choices with regard to the certificates it receives from D. 433 It can assume these certificates have been validated before they were 434 transmitted by D, or it can assume these certificates were not 435 validated before being transmitted by D. If B assumes D is validating 436 certificates before transmitting them, then B can place any 437 certificates received from D, an iBGP peer, directly into its local 438 databases. If B assumes D is not validating certificates before 439 transmitting them, then B can validate any received certificates 440 before placing them in its local database. These two options are 441 determined within the autonomous system, and do no impact soBGP's 442 inter-AS operation, nor the overall system operation. 444 5.3. Multihoming Deployment 446 Multihoming presents a special challenge to the deployment of soBGP 447 within a large scale internetwork. 449 (---------) (---------) 450 ( AS65401 ) ( AS65402 ) 451 ( ) ( ) 452 ( ) ( ) 453 (---A---) (---B---) 454 | | 455 \ / 456 \-----+ +-----/ 457 | | 458 (--C------D--) 459 ( ) 460 ( No-AS ) 461 (----------) 463 Assume No-AS has obtained a block of addresses, 10.1.1.0/24, from 464 AS65401, and would like to advertise that same block of addresses 465 through AS65402. Since No-AS has no AS number, it cannot generate 466 any soBGP certificates, and must rely on its upstream providers to 467 work out the security impact in some way. The simplest solution 468 would be, of course, for No-AS to obtain an AS number, and fully 469 participate in soBGP, but barring that, what other solutions are 470 there? 472 o AS65401 could issue a certificate allowing AS65402 to originate 473 just the prefix in question, 10.1.1.0/24. AS6402 could then 474 advertise this certificate. 475 o AS65401 could list AS65402 in the certificate covering 10.1.1.0/24 476 as an authorized originator for this address space (as multiple 477 authorized originators are allowed). 479 These options are also applicable to the case where No-AS receives an 480 address allocation, perhaps provided with a certificate as described 481 in [RFC3779]. No-AS can use these certificates, provided by the 482 authorizing entity to create and sign Authcerts containing the 483 autonomous system number of each of its service providers (or two 484 Authcerts, one for each service provider). 486 5.4. Proxy Advertisement of Certificates 488 Note there is no requirement for a given entity which originates 489 routes into the routing system to actually originate the 490 corresponding certificates required for the correct origination of 491 the route to be validated, and the AS Path attached to the route to 492 be verified. 494 (-----------------) 495 ( Other Third Party ) 496 (---------------) 497 / \ 498 / \ 499 (---------) (---------) 500 ( AS65401 ) ( AS65402 ) 501 ( ) ( ) 502 ( ) ( ) 503 (---A---) (---B---) 504 | | 505 \ / 506 \-----+ +-----/ 507 | | 508 (--C------D--) 509 ( ) 510 ( AS65403 ) 511 (----------) 513 In this case, AS65401, AS65402, or some other third part may actually 514 advertise the certificates necessary for AS65403 to originate 515 validated routes. 517 6. Other Considerations 519 In this section, we move from specific deployment scenarios to other 520 deployment considerations, such as key generation and protection, and 521 memory utilization/impact. 523 6.1. Certificate Generation and Private Key Protection 525 There is only one private/public key pair per autonomous system; 526 certificates are generated as determined by local policy and as 527 required to account for changes in the network. Since the entity's 528 private key is not used in any part of the operations verifying 529 received information, or in generating information to transmit to 530 other devices, these certificates could be generated on some secure 531 central system in the AS, and the results, containing only public 532 keys, can be transmitted throughout the network. 534 Securing the private key of each entity should be relatively easy in 535 this environment, since the location of the private key can be 536 carefully constrained; no device other than the system which 537 generates the required certificates needs use of the private key. 539 6.2. Impact on Performance and Memory Utilization 541 Detailed performance and memory utilization characteristics of soBGP 542 will be the subject of future investigation. However, as this is an 543 important area of consideration, we present some suggested analysis 544 below. (In other words, this is a guess). 546 In terms of memory, each device running soBGP will need to store: 548 o Each of the Entitycerts Received. The maximum number of 549 Entitycerts within the routing system would be the number 550 participating autonomous systems multiplied by the number of 551 outstanding Entitycerts from each autonomous system. 552 o Each of the ASPolicycerts Received. The number of ASPolicycerts 553 within the system will probably be similar to the number of 554 Entitycerts within the system. 555 o Each of the PrefixPolicycerts Received. The number of 556 PrefixPolicycerts within the system will depend on the number of 557 address blocks each participant in the routing system advertises, 558 and could double during key rollover. 560 Performance will depend on the cryptographic processing requirements 561 imposed by the certificate signature methods, as described in [SOBGP- 562 CERTIFICATE]. However, all of this additional memory and processing 563 would most likely be required on a distributed soBGP server, rather 564 than on routers themselves. 566 The primary impact on routers and routing protocol convergence will 567 be the memory and processing requirements added from the additional 568 route filters or processing as required by the deployment technique 569 used. 571 6.3. soBGP Impact on Internetwork Convergence 573 We generally assume that adding a security infrastructure on top of 574 an operating system will dramatically decrease the performance of 575 that system. However, much depends on the system being modified, 576 itself, and how closely to perfectly efficient that system already 577 performs. We've already examined, in prior sections, the impact of 578 soBGP on memory and processor utilization in devices running these 579 extensions, but we've not examined the impact of soBGP on another 580 aspect of an internetwork's operation, convergence time. In this 581 section, we will examine some possible side effects of deploying 582 soBGP using the following small internetwork as an example. 584 +--B--C--D--+ 585 | | 586 A---E---F---G---K 587 | | 588 +-----H-----+ 590 In this network, assume that: 592 o A prefers the path through {H,G} to K. 593 o E prefers the path through {F,G} to K. 594 o B prefers the path through {C,D,G} to K. 596 In this network, if the link from G to K fails: 598 o A will first receive a withdraw from H, and begin to prefer the 599 path through {E,F,G} to K. 600 o A will then receive a withdraw from E, and begin to prefer the 601 path through {C,D,E,G} to K. 602 o A will finally receive a withdraw from C, and remove the route to 603 K from its local tables. 605 This processing pattern is well documented through multiple studies 606 in the operations of [BGP] in large scale internetworks. The most 607 obvious answer to resolve this problem is for G to include some sort 608 of information in its withdraw indicating the nature of the failure, 609 so A can directly remove all paths through the link {G,K} on 610 receiving the first withdraw. This is more problematic than it 611 appears, however, because [BGP] is designed for protocol efficiency, 612 and withdraws are often removed from the internetwork, along with any 613 information they might contain, at an early point in the convergence 614 process. 616 The mechanism soBGP uses to build a graph of the interconnections 617 between the autonomous systems in the internetwork, however, provide 618 another place where this sort of direct information about changes in 619 the topology of the internetwork can be distributed. If this network 620 were running soBGP, G would be able to reissue its certificate 621 claiming connectivity to K, or use some specific policy indicator to 622 note the link {G,K} has failed. On receiving this certificate, all 623 the autonomous systems could remove all routes with the link {G,K} in 624 their AS Paths, and the network would converge with much less 625 distribution and processing of routing information. 627 We believe there are probably several performance enhancements that 628 may be gained through the laying of a connectivity graph on top of 629 the current [BGP] provided view of an internetwork. These types of 630 efficiency gains may overcome or fully offset the added costs of 631 deploying soBGP as a security system. 633 6.4. Aggregation 635 Aggregation is a diificult problem within any system attempting to 636 validate routes in an internetwork running BGP. The primary purpose 637 of aggregation is to remove information from the routing system, and 638 information removed from the system cannot be validated or verified. 639 This appears to be a simple observation, but it has a number of far 640 reaching impacts. 642 ( AS1 ) (AS4) (AS5) 643 10.1.0.0/24----A-----+ 644 | 645 ( AS2 ) | (AS5) 646 10.1.1.0/24----------B----C 647 | 648 ( AS3 ) | 649 10.1.2.0/24----------+ 651 In this small internetwork, B could be: 653 o Reoriginating 10.1.0.0/22 towards C. This means that rather than 654 building a BGP aggregate, B is simply generating 10.1.0.0.0/22 655 locally, and filtering all longer prefix components of this 656 aggregate. This is a common, normally recommended, practice, in 657 many situations. In this case, C will receive 10.1.0.0/22 with an 658 AS Path of {B}. 659 o Aggregating 10.1.0.0/22, using the aggregation procedure described 660 in [BGP]. In this case, B will generate an AS Set containing the 661 contributing autonomous system numbers. In this case, C will 662 receive 10.1.0.0/22 with an AS Path of {(1,2,3),4} 663 If B is reoriginating 10.1.0.0/22, C will not know this route is an 664 aggregate, and MUST treat the route as it does any other received 665 routing information. 667 If B is building an AS SET, C can examine the aggregator (the first 668 AS listed after the AS Path), and treat this AS as the originating 669 AS, verifying the route as it does any other received routing 670 information. If the internetwork's local policy rules require all 671 participants to run soBGP, and does not allow any AS to filter soBGP 672 certificates, C can also use the AS interconnection graph to verify B 673 is actually connected to each AS listed in the AS Set. 675 7. Incremental Deployment of soBGP 677 One of the primary concerns with any security system is the ability 678 of users to incrementally deploy the system without impacting current 679 network operations. As the security system is deployed, it should 680 provide greater security. In theory, the amount of additional 681 security offered verses the additional work required should be fairly 682 balanced. 684 There are two aspects of incremental deployment that need to be 685 considered: 687 o The impact of some of the participants in the system deploying the 688 security system, but not all participants deploy the system. 689 o The impact of some part of the system being deployed widely, but 690 not all of the system. 692 7.1. Not All Connected Networks Participate 694 The first consideration in incremental deployment of soBGP is asking 695 what happens if all of the autonomous systems in an internetwork 696 don't run soBGP. Is there any advantage to partial deployments of 697 soBGP in this sense? 699 Throughout this section, we will assume soBGP certificates are 700 received by all autonomous systems running soBGP, even if they are 701 separated by multiple hops which are not running soBGP. This is not 702 an unreasonable assumption, since soBGP certificates can be shared in 703 multiple ways, including multihop BGP sessions across non- 704 participating autonomous systems. 706 Assume we have the following small internetwork, what impact will 707 incrementally deploying soBGP through this network have? 709 (AS1) (AS2) (AS3) (AS4 ) 710 A-----B-----C-----D---10.1.1.0/24 712 Assume AS3 and AS4 deploy soBGP, but not AS1 and AS2; is there any 713 value in this partial deployment? When AS3 receives routes from AS4, 714 it can verify AS4 is authorized to advertise 10.1.1.0/24. Further, 715 any routes AS3 forwards to AS4 from AS1 or AS2 can be validated, to 716 some degree, by AS4. The AS Path can be checked to make certain AS2 717 is actually connected to AS3 (since AS3 is advertising its 718 connectivity to AS3). If some route is advertised from AS2 showing 719 an AS hop in the middle of those two autonomous systems, it can be 720 safely discarded by AS4 as an invalid AS Path. 722 We can make an alternate assumption, that AS1 and AS4 have deployed 723 soBGP, while AS2 and AS3 have not. In this case, what gains would be 724 made by deploying soBGP? Assume Router A receives a route from 725 Router B with an AS Path of {B,C,D}. If Router A has access to 726 Router D's certificates, it can: 728 o Check the origin AS (the first AS in the AS Path, in this case 729 AS4) is authorized to advertise the address space (in this case 730 10.1.1.0/24). 731 o Check the first hop in the AS Path (in this case AS3) is actually 732 attached to AS4, as advertised by AS4. 733 o Since Router A knows it is connected to AS2, through B, it can 734 also validate the last AS listed in the AS Path. 736 There is some gain, then, in deploying soBGP in both of these 737 situations. The gain is obviously more in the second scenario than 738 the first. 740 7.2. Deploying Parts of soBGP 742 The second question concerning incremental deploying is if 743 implementing some part of soBGP, without the remainder, would be 744 useful. This question is generally placed in the context of 745 validating the origination authorization of routes, and possibly the 746 first hop in the AS Path, but not the entire AS Path. 748 o soBGP Authcerts could be advertised or published (for instance, on 749 a Web page), to provide authorization for each origin AS to 750 advertise specific address blocks. These certificates could be 751 self signed, in the most relaxed case, or signed by the entity 752 authorizing the AS to advertise the address block. 753 o soBGP PrefixPolicycerts could be advertised or published (for 754 instance, on a web page), to provide authorization and first hop 755 checking for received routes. The Authcert within the 756 PrefixPolicycert contains the information required to validate the 757 origin's authorization to originate a route. The list of MAY 758 TRANSIT autonomous systems contained in the PrefixPolicycert would 759 provide the ability to check the first hop in the AS Path of any 760 received route. 761 o soBGP PrefixPolicycerts and ASPolicycerts could be advertised to 762 provide authorization to advertise a route from within an address 763 block, and also provide the ability to validate the first hop in 764 the AS Path. The Authcert, within the PrefixPolicycert, contains 765 the information required to validate the origin's authorization to 766 originate a route. The list of connected autonomous systems 767 within the ASPolicycert provides the information required to 768 validate the first hop in the AS Path of any received route. 770 Any of these modes of operation could be mixed with a full deployment 771 of soBGP, and provides checks for the first hop and origination of 772 received routes. 774 8. Policy Interactions with soBGP 776 Beyond simply securing the information contained within the routing 777 database [BGP] builds, it's also desirable to have a secure mechanism 778 for an autonomous system to advertise policy information. For 779 instance, an autonomous system may not want a specific peer to 780 transit traffic, or an originator may want routing information to be 781 advertised only to a specific number of AS hops away from the origin. 783 The sections below examine some various policies of this type, and 784 possible solutions within soBGP. 786 8.1. Indicating Do Not Transit 788 In the following small internetwork, A would like to enforce a policy 789 preventing C from transiting traffic from B to A. 791 A-------B--------D 792 | | 793 +---C---+ 795 A may attempt to prevent C from transiting traffic from B to A by 796 advertising its routing information to C in such a way that C cannot 797 readvertise that routing information to B. The problem with this 798 approach is that B must assume the lack of specific routing 799 information from C indicates A has a local policy forbidding C from 800 transiting traffic to A. Unfortunately, because of the nature of 801 address space assignment, aggregation, filtering, and other factors, 802 B cannot make this assumption. For instance, C may receive a 803 superset of the routing information A is advertising, and advertise 804 those routes to B instead, in which case A will find there's no 805 effective way to enforce its policy towards C. 807 We find, however, that the interconnection graph laid on top of the 808 routing information transmitted by each autonomous system provides a 809 point where A may communicate its nontransit policy towards C 810 directly to B. Using its ASPolicycert, A may indicate B is not a 811 transit AS, allowing B to mark routes with the AS pair {B,A} in their 812 AS Path with a lower security preference, or possibly even discarding 813 such routing information altogether. 815 This is a simple application of the policies available in the soBGP 816 certificates; more complex policies may be expressed through similar 817 means. The certificates described in [SOBGP-CERTIFICATE] are built 818 so policies may be added in the future, as well. 820 9. Acknowledgements 822 A large number of people contributed to this draft either by 823 contributing text, ideas, or comments; we've tried to include all of 824 them here (but might have missed a few): James Ng, Tim Gage, Alvaro 825 Retana, Dave Cook, Brian Weis, Iljitsch van Beijnum, Bora Akyol, Tony 826 Li, Sue Hares, and Victor P. Long. 828 10. Security Considerations 830 11. IANA Considerations 832 12. References 834 12.1. Normative References 836 [BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 837 (BGP-4)", RFC 1771, March 1995. 839 [SOBGP-CERTIFICATE] 840 Weiss, B., "Secure Origin BGP (soBGP) certificates", 841 draft-weis-sobgp-certificates-01.txt (work in progress), 842 October 2003. 844 12.2. Informative References 846 [COST] Retana, A. and R. White, "BGP Custom Decision Process", 847 draft-retana-bgp-custom-decision-00.txt (work in 848 progress), October 2002. 850 [PATH-CONSIDER] 851 White, R., "Considerations in Validating the Path in 852 Routing Protocols", draft-white-pathconsiderations-02.txt 853 (work in progress), April 2004. 855 [SOBGP-BGPTRANSPORT] 856 Ng, J., "Extensions to BGP Transport soBGP certificates", 857 draft-ng-sobgp-bgp-extensions-01.txt (work in progress), 858 April 2004. 860 [SOBGP-RADIUS] 861 Lonvick, C., "RADIUS Attributes for soBGP Support", 862 draft-lonvick-sobgp-radius-04.txt (work in progress), 863 February 2004. 865 Author's Address 867 Russ White, editor 868 Cisco Systems 870 Email: riw@cisco.com 872 Intellectual Property Statement 874 The IETF takes no position regarding the validity or scope of any 875 Intellectual Property Rights or other rights that might be claimed to 876 pertain to the implementation or use of the technology described in 877 this document or the extent to which any license under such rights 878 might or might not be available; nor does it represent that it has 879 made any independent effort to identify any such rights. Information 880 on the procedures with respect to rights in RFC documents can be 881 found in BCP 78 and BCP 79. 883 Copies of IPR disclosures made to the IETF Secretariat and any 884 assurances of licenses to be made available, or the result of an 885 attempt made to obtain a general license or permission for the use of 886 such proprietary rights by implementers or users of this 887 specification can be obtained from the IETF on-line IPR repository at 888 http://www.ietf.org/ipr. 890 The IETF invites any interested party to bring to its attention any 891 copyrights, patents or patent applications, or other proprietary 892 rights that may cover technology that may be required to implement 893 this standard. Please address the information to the IETF at 894 ietf-ipr@ietf.org. 896 Disclaimer of Validity 898 This document and the information contained herein are provided on an 899 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 900 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 901 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 902 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 903 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 904 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 906 Copyright Statement 908 Copyright (C) The Internet Society (2006). This document is subject 909 to the rights, licenses and restrictions contained in BCP 78, and 910 except as set forth therein, the authors retain all their rights. 912 Acknowledgment 914 Funding for the RFC Editor function is currently provided by the 915 Internet Society.