idnits 2.17.1 draft-white-pathconsiderations-09.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, updated by RFC 4748 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 727. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 733. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 82 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 11, 2007) is 6164 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) == Unused Reference: 'S-BGP' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'SOBGP' is defined on line 672, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. 'BGP-MD5') (Obsoleted by RFC 5925) == Outdated reference: A later version (-02) exists of draft-white-sobgp-architecture-00 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. White 2 Internet-Draft B. Akyol 3 Expires: December 13, 2007 Cisco Systems 4 June 11, 2007 6 Considerations in Validating the Path in BGP 7 draft-white-pathconsiderations-09 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 13, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document examines the implications of hop by hop forwarding, 41 route aggregation, and route filtering on the concept of validation 42 within a BGP AS Path. 44 1. Background 46 A good deal of thought has gone into, and is currently being given 47 to, validating the path to a destination advertised by BGP. The 48 purpose of this work is to explain the issues in validating a BGP AS 49 Path, in the expectation that it will help in the evaluation of 50 schemes seeking to improve path validation. The first section 51 defines at least some of the types of questions a BGP speaker 52 receiving an update from a peer not in the local autonomous system 53 (AS) could ask about the information within the routing update. The 54 sections following examine the answers to these questions in 55 consideration of specific deployments of BGP. 57 The examples given in this draft are intended to distill deployments 58 down to their most critical components, making the examples easier to 59 understand and consider. In many situations, the specific path taken 60 in the example may not be relevant, but that does not nullify the 61 principles considered in each example. It has been suggested that 62 these examples are "red herrings," because they do not illustrate 63 actual problems with specific policies. On the contrary, these 64 examples are powerful because they are simple. Any topology in which 65 one of these example topologies is a subtopology will exhibit the 66 characteristics explained in this draft. Rather than focusing on a 67 specific topology, then dismissing that single topology as a "corner 68 case," this draft shows the basic issues with assertions about the AS 69 Path attribute within BGP. These generalized issues can then be 70 applied to more specific cases. 72 With the heightened interest in network security, the security of the 73 information carried within routing systems running BGP, as describued 74 in [RFC4271], is being looked at with great interest. While there 75 are techniques available for securing the relationship between two 76 devices exchanging routing protocol information, such as [BGP-MD5], 77 these techniques do not ensure various aspects of the information 78 carried within routing protocols are valid or authorized. 80 The following small internetwork is used to examine the concepts of 81 validity and authorization within this draft, providing definitions 82 used through the remainder of the draft. 84 10.1.1.0/24--(AS65000)---(AS65001)--(AS65002) 86 Assume a BGP speaker in AS65002 has received an advertisement for 87 10.1.1.0/24 from a BGP speaker in AS65001, with an AS Path of {65000, 88 65001}. 90 1.1. Is the Originating AS Authorized to Advertise Reachability to the 91 Destination? 93 The most obvious question the receiving BGP speaker can ask about 94 this advertisement is whether or not the originating AS, in this case 95 AS65000, is authorized to advertise the prefix contained within the 96 advertisement, in this case 10.1.1.0/24. Whether or not a BGP 97 speaker receiving a route to 10.1.1.0/24 originating in AS65000 can 98 verify that AS65000 is, indeed, authorized to advertise 10.1.1.0/24 99 is outside the scope of this draft. 101 1.2. Is the Path Contained in the Advertised Routing Information Valid? 103 If a BGP speaker receives an advertisement from a peer outside the 104 local autonomous system (AS), the peer sending the update has a path 105 to the destination prefix in the update. Specifically, are the 106 autonomous systems within the internetwork connected in such a way 107 that the receiver, following the AS Path listed in the BGP update 108 itself, can reach the originating AS listed in the received AS Path? 109 Within this draft, this is called path validation. 111 Path validation, in the context of this small internetwork, asserts 112 that when a BGP speaker in AS65002 receives an advertisement from a 113 BGP speaker in AS65001 with the AS Path {65000, 65001}, the speaker 114 can assume that AS65001 is attached to the local AS, and that AS65001 115 is also attached to AS65000. 117 1.3. Is the Advertisement Authorized? 119 There are at least three senses in which the readvertisement of a 120 received advertisement can be authorized in BGP: 122 o The transmitter is authorized to advertise the specific routing 123 information contained in the route. This treats the routing 124 information as a single, atomic unit, regardless of the 125 information the route actually contains. A route to 10.1.1.0/24 126 and another route to 10.1.0.0/16 are considered completely 127 different advertisements of routing information, so an AS may be 128 authorized advertise 10.1.0.0/16 without regard to its 129 authorization to advertise 10.1.1.0/24, since these are two 130 separate routes. This is called route authorization throughout 131 this draft. 132 o The transmitter is authorized to advertise the specific reachable 133 destination(s) contained in the route. This treats the routing 134 information as a set of destinations. 10.1.1.0/24 is contained 135 within 10.1.0.0/16, and authorization to advertise the latter 136 implies authorization to advertise the former. This is called 137 reachability authorization throughout this draft. 138 o The transmitter is authorized to transit traffic to the 139 destinations contained within the route. This ties the concepts 140 of the route to what the route is used for. If a BGP speaker is 141 advertising reachability to 10.1.1.0/24, it is authorized to 142 transit traffic to all reachable destinations within 10.1.1.0/24 143 along the path advertised. This is called transit authorization 144 throughout this draft. 146 There is considerable tension between these three defintions of 147 authorization; much of this draft is built around exploring the 148 relationships between these different types of authorization, and how 149 they may, or may not, work in various internetworks. One of the 150 conclusions reached by this draft is that route authorization, 151 reachability authorization, and transit authorization are often at 152 odds with each other. Showing one type of authorization to be true 153 does not show any other types of authorization to be true, and route 154 authorization is of questionable value because of the intertwined 155 nature of these three types of authorization in a routing system. 157 1.4. Will Traffic Forwarded to an Advertising Speaker Follow the 158 Described AS Path? 160 If a BGP speaker receives an advertisement from a peer not in the 161 local AS, will traffic forwarded to the peer advertising the update 162 will follow the path described in the AS Path? In this draft, this 163 is called forwarding consistency. 165 In terms of the small example internetwork, if a BGP speaker in 166 AS65002 receives an advertisement from a peer in AS65001 for the 167 destination 10.1.1.0/24, with an AS Path {65000, 65001}, will traffic 168 forwarded to the BGP speaker in AS65001 actually be forwarded through 169 routers within AS65001, then AS65000, to reach their destination? 171 1.5. Is a Withdrawing Speaker Authorized to Withdraw the Routing 172 Information? 174 If an advertisement is withdrawn, the withdrawing BGP peer was 175 originally advertised the prefix (or was authorized to advertise the 176 prefix). This assertion is out of the scope of this draft. 178 2. Analysis 180 To begin, we review some of the concepts of routing, since we need to 181 keep these concepts fixed firmly in place while we examine these 182 questions. After this, four examples will be undertaken with BGP to 183 show the tension between the various types of authorization in a path 184 vector routing system. 186 2.1. A Short Analysis of Routing 188 Routing protocols are designed, in short, to discover a set of loop 189 free paths to each reachable destination within a network (or 190 internetwork). The loop free path chosen to reach a specific 191 destination may not be the shortest path, and it may not always be 192 the "best" path (depending on the definition of "best"), but it 193 should always be a loop free path, or routing, and the routing 194 protocol, has failed. 196 This sheds some light on the purpose of the path included in an path 197 vector protocol's routing update: the path is there to prove the path 198 is loop free, rather than to provide any other information. While 199 Dijkstra's SPF and the Diffusing Update Algorithm (DUAL) both base 200 their loop free path calculations on the cost of a path, path vector 201 protocols, such as BGP, prove a path is loop free by carrying a list 202 of nodes the advertisement itself has traversed. BGP specifically 203 uses an AS Path based mechanism to prove loop freeness for any given 204 update so each AS along the path may implement local policy without 205 risking a loop in the routing system caused by competing metrics. 207 We need to keep this principle in mind when considering the use of 208 the path carried in a path vector protocol, and its use by a 209 receiving BGP speaker for setting policy or gauging the route's 210 security level. 212 2.2. First Example: Manual Intervention in the Path Choice 214 In the small network: 216 +---(AS65002)---+ 217 (AS65000)--(AS65001) (AS65004)--10.1.1.0/24 218 +---(AS65003)---+ 220 A BGP speaker in AS65000 may receive an advertisement from a peer 221 that 10.1.1.0/24 is reachable along the path {65004, 65002, 65001}. 222 Based on this information, the BGP speaker may forward packets its 223 peer in AS65001, expecting them to take the path described. However, 224 within AS65001, the network administrator may have configured a 225 static route making the next hop to 10.1.1.0/24 the edge router with 226 AS65003. 228 It's useful to note that while [RFC4271] states: "....we assume that 229 a BGP speaker advertises to its peers only those routes that it 230 itself uses...," the definition of the term "use" is rather loose in 231 all known widely deployed BGP implementations. Rather than meaning: 232 "A BGP speaker will only advertise destinations the BGP process on 233 the speaker has installed in the routing table," it generally means: 234 "A BGP speaker will only advertise destinations that the local 235 routing table has a matching route installed for, no matter what 236 process on the local router installed the route." A naive reaction 237 may be to simply change the BGP specifications, and all existing 238 implementations so a BGP speaker will only advertise a route to a 239 peer if the BGP process on the router actually installed the route in 240 the local routing table. This, however, ignores the complex 241 interactions between interior and exterior gateway protocols, which 242 most often run on the same device, and the complexities of route 243 origination. 245 Although this is an "extreme" example, since we can hardly claim the 246 information within the routing protocol is actually insufficient, we 247 will still find it instructive to examine this example in light of 248 the questions outlined in Section 1: 250 o Is the AS Path valid? The AS Path the receiving BGP speaker in 251 AS65000 receives from its peer in AS65001, {65004, 65002, 65001), 252 does exist, and is valid. 253 o Is the advertisement authorized? Since we have no knowledge of 254 any autonomous system level policy within this network, we have no 255 way of answering this question. We can assume that AS65001 has 256 both route and reachability authorization, but is difficult to see 257 how transit authorization can be accomplished in this situation. 258 Even if theBGP speaker in AS65000 could verify AS65001 is 259 authorized to transit AS65002 to reach 10.1.1.0/24, this implies 260 nothing about the authorization to transit traffic through the 261 path traffic will actually take, which is through AS65003. 262 o Is the AS Path consistent with the forwarding path (does 263 forwarding consistency exist)? No; the advertised AS Path is 264 {65004, 65002, 65001}, while the actual path is {65004, 65003, 265 65001}. 267 From this example, we can see forwarding consistency is not possible 268 to validate in a deployed network; just because a BGP speaker 269 advertises a specific path to reach a given destination, there is no 270 reason to assume traffic forwarded to the speaker will actually 271 follow the path advertised. In fact, we can reason this from the 272 nature of packet forwarding networks; each router along a path makes 273 a completely separate decision about where to forward received 274 traffic. Any router along the path could actually change the path 275 due to network conditions without notifying, in any way, upstream 276 routers, so at any given time, an upstream router may be forwarding 277 traffic along a path that no longer exists, or is no longer optimal, 278 and downstream routers could be correcting the forwarding decision by 279 placing the traffic on another available path unknown to the upstream 280 router. 282 As a corollary, we can see that authorizing transit through a 283 specific AS Path is not possible, either. If the source of a 284 specific flow cannot know what path the traffic within that flow will 285 take to reach the destination, then there is no meaningful sense in 286 which downstream routers can authorize the source to use available 287 paths for transiting traffic. 289 2.3. Second Example: An Unintended Reachable Destination 291 In this internetwork, we assume a single policy: The system 292 administrator of AS65000 would not like the destination 10.1.1.0/24 293 to be reachable from any autonomous system beyond AS65001. In other 294 words, 10.1.1.0/24 should be reachable within AS65001, but not to 295 autonomous systems connected to AS65001, such as AS65002. 296 10.1.1.0/24---(AS65000)---(AS65001)---(AS65002) 298 The system administrator can implement this policy by casuing BGP 299 speakers within AS65000 to advertise 10.1.1.0/24 to peers within 300 AS65001 with a signal that the BGP speakers in AS65001 should not 301 readvertise reachability this routing information. For example, BGP 302 speakers in AS65000 could advertise the route to 10.1.1.0/24 with the 303 NO_ADVERTISE community attached, as described in [RFC4271]. If the 304 BGP speakers in AS65001 are configured to correctly respond to this 305 community (and we assume they are for the purposes of this draft), 306 they should accept this advertisement, but not readvertise 307 reachability to 10.1.1.0/24 into AS65002. 309 However, unknown to the system administrator of AS65000, AS65001 is 310 actually advertising a default route to AS65002 with an AS Path of 311 {65001}, and not a full routing table. If some host within AS65002, 312 then, originates a packet destined to 10.1.1.1, what will happen? 313 The packet will be routed according to the default route from AS65002 314 into AS65001. Routers within AS65001 it will forward the packet 315 along the 10.1.1.0/24 route, eventually forwarding the traffic into 316 AS65000. 318 o Is the AS Path valid? This is a difficult question to answer, 319 since there are actually two different advertisements in the 320 example. From the perspective of the BGP speaker in AS65002 321 receiving a default route in an advertisement from a peer in 322 AS65001, the AS Path to the default route is valid. However, 323 there is no route to 10.1.1.0/24 for the BGP speaker in AS65002 to 324 examine for validity, so the question appears to be out of scope 325 for this example. 326 o Is the AS Path consistent with the forwarding path (is there 327 forwarding consistency)? From the perspective of a BGP speaker in 328 AS65002, traffic forwarded to AS65001 towards a destination within 329 10.1.1.0/24 is actually going to terminate within AS65001, since 330 that is the entire AS Path for the default route. However, this 331 traffic actually transits AS65001 towards AS65000. Therefore, 332 forwarding consistency does not exist in this example. In this 333 example we are dealing with a case of aggregation, and as section 334 9.1.4 of [RFC4271], in reference to aggregated routing 335 information, states: "Forwarding along such a route does not 336 guarantee that IP packets will actually traverse only ASes listed 337 in the AS_PATH attribute of the route." 339 2.3.1. Advertisement Authorization 341 Is the advertisement authorized? This example higlights the tension 342 between the three different types of authorization. The three 343 following sections discuss issues with different advertisements 344 AS65001 may send to AS65002. 346 2.3.1.1. Valid Unauthorized Aggregates 348 The first issue that comes up in this example is the case where there 349 is no expectation of authorization for aggregation. The most common 350 example of this is the advertising and accepting of the default route 351 (0/0). This is a common practice typically done by agreement between 352 the two parties. Obviously, there is not authorization process for 353 such an advertisement. This advertisement may extend reachability 354 beyond originators intention (along the lines of the previous 355 example). It may cause packets to take paths not known by the sender 356 (since the path on 0/0 is simply the advertising AS.) It may violate 357 other security constraints. This places limits on the power and 358 applicability of efforts to secure the AS path and AS policies. It 359 does not vitiate the underlying value in such efforts. 361 2.3.1.2. Owner Aggregation 363 In the current instantiation of IP address allocation, an AS may 364 receive authorization to advertise 10.1.0.0/16, for instance, and may 365 authorize some other party to use (or own) 10.1.1.0/24, a subblock of 366 the space authorized. This is called a suballocation. 368 For instance, in this example, if AS65001 were authorized to 369 originate 10.1.0.0/16, it could advertise 10.1.0.0/16 towards 370 AS65002, rather than a default route. Assume there is some form of 371 authorization mechanism AS65002 can consult to verify AS65001 is 372 authorized to advertise 10.1.0.0/16. In this case, AS65002 could 373 examine the authorization of AS65001 to originate 10.1.0.0/16, and 374 assume that if AS65002 is authorized to advertise 10.1.0.0/16, it is 375 also authorized to transit traffic towards every possible subblock of 376 (every destination within) 10.1.0.0/16. To put this in more distinct 377 terms: 379 o AS65002 verifies route authorization by examining the 380 authorization of AS65001 to advertise 10.1.0.0/16. 382 o AS65002 assumes destination authorization, that AS65001 has the 383 authorization to advertise every possible subblock of 10.1.0.0/16, 384 because AS65001 is authorized to advertise 10.1.0.0/16. 385 o AS65002 assumes transit authorization, that AS65001 has the 386 authorization to transit traffic to every possible subblock of 387 10.1.0.0/16, because AS65001 is authorized to advertise 388 10.1.0.0/16. 389 From the example given, however, it's obvious route authorization 390 does not equal destination or transit authorization. While AS65001 391 does have route authorization to advertise 10.1.0.0/16, it does not 392 have destination authorization to advertise 10.1.1.0/24, nor transit 393 authorization for destinations with 10.1.1.0/24. 395 The niave reply to this would be to simply state that destination and 396 transit authorization should not be assumed from route authorization. 397 However, the problem is not that simple to resolve. The assumption 398 of destination authorization and transit authorization are not 399 decisions AS65002 actually makes; they are embedded in the way the 400 routing system works. The route itself, within the design of 401 routing, carries these implications. 403 Why does routing intertwine these three types of authorization? Most 404 simply, because AS65002 does not have any information about subblocks 405 that are part of 10.1.0.0/16. There is no way for AS65002 to check 406 for destination and transit authorization because this information is 407 removed from the system altogether. In order to show destination and 408 transit authorization, this information must be reinjected into the 409 routing system in some way. 411 For instance, considering destination authorization alone, it is 412 possible to envision a system where AS65001, when suballocating part 413 of 10.1.0.0/16 to the originator, must also obtain permission to 414 continue advertising the original address block as an aggregate, to 415 attempt to resolve this problem. However, this raises some other 416 issues. 418 o If the originator did not agree to AS65001 advertising an 419 aggregate containing 10.1.1.0/24, then AS65001 would be forced to 420 advertise some collection of advertisements not containing the 421 suballocated block. 422 o If AS65001 actually does obtain permission to advertise the 423 aggregate, we must find some way to provide AS65002 with 424 information about this authorization for each possible subblock of 425 10.1.0.0/16. 426 In other words, either AS65002 must receive the actual routes for 427 each suballocation of 10.1.0.0/16, or it must receive some form of 428 authorization allowing AS65001 to advertise each suballocation of 429 10.1.0.0/16. This appears to defeat the purpose of aggregation, 430 rendering routing systems much less scalable than current design 431 allows. Further, this does not resolve the issue of how AS65002 432 would actually know what all the suballocations of 10.1.0.0/16 433 actually are. Some possible solutions could be: 435 o The suballocator must advertise all suballocations. This could 436 potentially expose business relationships and patterns that many 437 large commecial providers do not want to expose, and degrades the 438 hierarchical nature of suballocation altogether. 439 o The IP address space must be reconstructed so everyone using IP 440 address space will know, based on the construction of the IP 441 address space, what subblocks exist. For instance, the longest 442 allowed subblock could be set at a /24, and authorization must be 443 available for every possible /24 in the address space, either for 444 origination, or as part of an aggregate. This sort of solution 445 would be an extreme burden on the routing system. 447 2.3.1.3. Proxy Aggregation 449 It is also possible for AS65001 to have some form of agreement with 450 AS65002 to aggregate blocks of address space it does not own towards 451 AS65002. This might be done to reduce the burden on BGP speakers 452 within AS65002. This is called proxy aggregation. While proxy 453 aggregation is rare, it is useful to examine the result of agreed to 454 proxy aggregation in this situation. 456 Assume AS65001 has an advertisement for 10.1.0.0/24 from some unknown 457 source, and decides to advertise both 10.1.0.0/24 and 10.1.1.0/24 as 458 10.1.0.0/23 to AS65002. If there exists an agreement for AS65001 to 459 advertise proxy aggregates to AS65002, the latter will accept the 460 advertisement regardless of any attached authorization to advertise. 461 This may represent a security risk for AS65002, but it might be seen 462 as an acceptable risk considering the tradeoffs, from AS65002's 463 perspective. 465 The problem is, however, this also impacts the policies of AS65000, 466 which is originating one of the two routes being aggregated by 467 AS65001. There is no way for AS65002 to know about this policy, nor 468 to react to it, and there is actually no incentive for AS65002 to 469 react to a security threat posed to AS65000, which it has no direct 470 relationship with. There doesn't appear to be any immediately 471 available solution to solve this problem, other than to disallow 472 proxy aggregation, even between two cooperating autonomous systems. 474 2.3.2. Implications 476 The basic problem is that AS65002 assumes when AS65001 advertises an 477 authorized route containing 10.1.1.0/24, either through a valid 478 unauthorized aggregate, an owner aggregated route, or a proxy 479 aggregation, AS65001 also has destination authorization for the 480 subblock 10.1.1.0/24, and transit authorization for destinations 481 within 10.1.1.0/24. These are, in fact, invalid assumptions, but 482 they are tied to the way routing actually works. This shows the 483 value of route authorization is questionable, unless there is some 484 way to untie destination and transit authorization from route 485 advertisements, which are deeply intertwined today. 487 2.4. Third Example: Following a Specific Path 489 This example is slightly more complex than the last two. Given the 490 following small network, assume that A and D have a mutually agreed 491 on policy of not allowing traffic to transit B to reach destinations 492 within 10.1.1.0/25. 493 10.1.1.0/25--A---B---C---D 494 | | | 495 E-------F---G 497 Assume the following: 499 o A advertises 10.1.1.0/25 to B, and 10.1.1.0/24 to E. 500 o B advertises 10.1.1.0/25 {B,A} to C. 501 o E advertises 10.1.1.0/24 {E,A} to F, filtering 10.1.1.0/25 {E,A} 502 based on some local policy. 503 o F advertises 10.1.1.0/24 {F,E,A} to C and to G. 504 o C advertises 10.1.1.0/24 {C,F,E,A} to D, filtering 10.1.1.0/25 505 {B,A} based on some local policy. 506 o G advertises 10.1.1.0/24 {G,F,E,A} to D. 507 o D chooses 10.1.1.0/24 {C,F,E,A} over 10.1.1.0/24 {G,F,E,A}. 509 What path will traffic forwarded to C destined to hosts within 510 10.1.1.0/25 actually follow? 512 o D forwards this traffic to C, since its best path is through 513 10.1.1.0/24 {C,F,E,A}. 514 o C forwards this traffic to B, since its best path is through 515 10.1.1.0/25 {B,A}. 516 o B forwards this traffic to A, since its best path is thorugh 517 10.1.1.0/25 {A} 518 Considering this result: 520 o Is the AS Path valid? Both {G, F, E, A} and {C, F, E, A} are 521 valid AS Paths, so both AS Paths in this example are valid. 522 o Is the advertisement authorized? Assuming A is authorized to 523 advertise 10.1.1.0/24, and all the autonomous systems in the 524 example are authorized to readvertise 10.1.1.0/24, the route is 525 authorized. However, C does not have destination nor transit 526 authorization to 10.1.1.0/25, since B is the best path from C to 527 10.1.1.0/25, and D and A have explicit policies not to transit 528 this path. In effect, then C does not have destination or transit 529 authorization for 10.1.1.0/24, because it contains 10.1.1.0/25. 530 o Is the AS Path consistent with the forwarding path (is there 531 forwarding consistency)? While C is advertising the AS Path {C, 532 F, E, A} to D to reach destinations within 10.1.1.0/24, it is 533 actually forwarding along a different path to some destinations 534 within this advertisement. Forwarding consistency does not exist 535 within this internetwork. 537 In this example, A asssumes that D will receive both the 538 advertisement for 10.1.1.0/24 and the advertisement for 10.1.1.0/25, 539 and will be able to use the included AS Path to impose their mutually 540 agreed on policy not to transit B. Information about 10.1.1.0/25, 541 however, is removed from the routing system by policies outside the 542 knowledge or control of A or D. The information remaining in the 543 routing system implies D may correctly route to destinations within 544 10.1.1.0/25 through C, since 10.1.1.0/25 is contained within 545 10.1.1.0/24, which C is legally advertising. 547 The tension between route authorization, destination authorization, 548 and transit authorization can be seen clearly in this slightly more 549 complex example. Route authorization implies destination and transit 550 authorization in routing, but route authorization does not include 551 destination or prefix authorization in this example. 553 2.5. Fourth Example: Interior and Exterior Paths Mismatch 555 This is the most complex example we will cover in this draft. It can 556 be argued that the configuration described in this example is a 557 misconfiguration, but we have chosen this example for its simplicity, 558 as an illustration of the complexity of the interaction between 559 interior and exterior gateway protocols within an autonomous system. 560 BGP route reflectors, particularly when configured in a hierarchy, 561 provide many examples of forwarding inconsistency, but they are much 562 more complex than this small example. 563 +-----F(9)---------------G(3)--------+ 564 | | | 565 | +------+ | 566 | | | 567 | +---C(2)--+ | 568 | | | | 569 A(1)-----B(2) +----------------E(5)--10.1.1.0/24 570 | | | | 571 | +---D(2)--+ | 572 | | 573 +------------------H(6)--J(7)--K(8)--+ 575 In this diagram, each router is labeled, with the AS it is in 576 contained in parenthesis following the router label. Each router is 577 using, as its best path to 10.1.1.0/24: 579 o Router E is using its local (intra-AS) path. 580 o Router C is using the path through AS3. 581 o Router D is using the path through Router E. 582 o Router B is using the path through Router E. 584 Examining the case of Router B more closely, however, we discover 585 that while Router B prefers the path it has learned from Router E, 586 that path has been advertised with a next hop of Router E itself. 587 However, Router B's best path to this next hop (i.e., Router E), as 588 determined by the interior routing protocol, is actually through 589 Router C. Thus, Router B advertises the path {2, 5} to Router A, but 590 traffic actually follows the path {2, 3, 5} when Router B receives 591 it. 593 The system administrator of AS1 has determined there is an attacker 594 in AS3, and has set policy on router A to avoid any route with AS3 in 595 the AS_PATH. So, beginning with this rule, it discards the path 596 learned from AS9. It now examines the two remaining paths, learned 597 from AS2 (B) and AS6, and determines the best path is {2, 5}, through 598 AS2 (B). However, unknown to A, AS2 (B) is also connected to AS3, 599 and is transiting traffic to AS5 via the path {2, 3, 5}. 601 Returning to our questions: 603 o Is the AS Path valid? The AS Path {2, 3, 5} is a valid AS Path. 604 o Is the route authorized? Assuming each AS along the path is 605 authorized to originate, or readvertise, 10.1.1.0/24, the route is 606 authorized. Destination authorization is also clear in this 607 situation, since 10.1.1.0/24 is the single destination throughout 608 the example. Transit authorization is a little more difficult to 609 determine, since the traffic doesn't actually flow along the AS 610 Path contained in the routing advertisement. It's impossible to 611 claim the AS Path {2,3,5} is a valid path from either the route 612 originator or the traffic originator, since that AS Path is not 613 the AS Path advertised. Essentially, Router E assumes transit 614 authorization from route authorization, when there is no way to 615 determine that AS3 is actually authorized to transit traffic to 616 10.1.1.0/24. 617 o Is the AS Path consistent with the forwarding path (is there 618 forwarding consistency)? The advertised AS Path is {2, 5}, while 619 the traffic forwarded to the destination actually transits {2, 3, 620 5}. Forwarding is not consistent in this example. 622 3. Summary 624 The examples given in this draft are not the only possible examples 625 of forwarding that is inconsistent with the advertised AS Path; 626 [ROUTINGLOGIC] also provides some examples, as well. [ASTRACEROUTE] 627 provides some interesting background on the pratical impact of 628 forwarding inconsistent with the advertised AS Path, in the context 629 of attempting to trace the actual path of packets through a large 630 internetwork running BGP as an exterior gateway protocol. 632 Routing strongly intertwines the concepts of route authorization, 633 destination authorization, and transit authorization. If a BGP 634 speaker is authorized to advertise a specific route, routing assumes 635 that it is also authorized to advertise every possible subblock 636 within the destination prefix, and the advertiser is authorized to 637 transit packets to every destination within the route. By surveying 638 these examples, we see that route authorization does not, in fact, 639 equal destination authorization, or transit authorization, calling 640 into question the value of route authorization. 642 There are no easy or obviously scalable solutions to this problem. 644 4. Acknowledgements 646 We would like to thank Steve Kent for his contributions and comments 647 on this draft. We would also like to thank Joel Halpern for his work 648 in clarifying many sections of the draft, including addtional text in 649 critical sections. 651 5. Informative References 653 [ASTRACEROUTE] 654 Feamster, N. and H. Balakrishnan, "Towards an Accurate 655 ASLevel Traceroute Tool", SIGCOMM ACM SIGCOMM, 2003. 657 [BGP-MD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 658 Signature Option", RFC 2385, August 1998. 660 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 661 Protocol 4 (BGP-4)", RFC 4271, January 2006. 663 [ROUTINGLOGIC] 664 Feamster, N. and H. Balakrishnan, "Towards a Logic for 665 Wide Area Routing", SIGCOMM ACM SIGCOMM Worshop on Future 666 Directions in Network Architecture, Germany, August 2003. 668 [S-BGP] Kent, S., Lynn, C., and K. Seo, "Secure Border Gateway 669 Protocol (Secure-BGP)", IEEE IEEE Journal on Selected 670 Areas in Communications, April 2000. 672 [SOBGP] White, R., "Architecture and Deployment Considerations for 673 Secure Origin BGP (soBGP)", 674 draft-white-sobgp-architecture-00.txt (work in progress), 675 April 2004. 677 Authors' Addresses 679 Russ White 680 Cisco Systems 682 Phone: 683 Fax: 684 Email: riw@cisco.com 685 URI: 687 Bora Akyol 688 Cisco Systems 690 Phone: 691 Fax: 692 Email: bora@cisco.com 693 URI: 695 Full Copyright Statement 697 Copyright (C) The IETF Trust (2007). 699 This document is subject to the rights, licenses and restrictions 700 contained in BCP 78, and except as set forth therein, the authors 701 retain all their rights. 703 This document and the information contained herein are provided on an 704 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 705 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 706 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 707 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 708 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 709 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 711 Intellectual Property 713 The IETF takes no position regarding the validity or scope of any 714 Intellectual Property Rights or other rights that might be claimed to 715 pertain to the implementation or use of the technology described in 716 this document or the extent to which any license under such rights 717 might or might not be available; nor does it represent that it has 718 made any independent effort to identify any such rights. Information 719 on the procedures with respect to rights in RFC documents can be 720 found in BCP 78 and BCP 79. 722 Copies of IPR disclosures made to the IETF Secretariat and any 723 assurances of licenses to be made available, or the result of an 724 attempt made to obtain a general license or permission for the use of 725 such proprietary rights by implementers or users of this 726 specification can be obtained from the IETF on-line IPR repository at 727 http://www.ietf.org/ipr. 729 The IETF invites any interested party to bring to its attention any 730 copyrights, patents or patent applications, or other proprietary 731 rights that may cover technology that may be required to implement 732 this standard. Please address the information to the IETF at 733 ietf-ipr@ietf.org. 735 Acknowledgment 737 Funding for the RFC Editor function is provided by the IETF 738 Administrative Support Activity (IASA).