RFC 5123

Considerations in Validating the Path in BGP

📅 published February 2008, from ietf

Considerations in Validating the Path in BGP 💖

okay bestie, this one is RFC 5123, and it's called "Considerations in Validating the Path in BGP" 🎀 It was written by R. White and B. Akyol from Cisco Systems and published in February 2008. It's Informational, so it's sharing knowledge with the internet community and is not a standard 🧚 The header doesn't list any RFCs it obsoletes or updates, so it doesn't touch anything else. 🫶

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

IESG Note 📝

After consultation with the RPSEC WG, the IESG thinks that this work is related to IETF work done in WG RPSEC, but this does not prevent publishing.

This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion.

Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. 🙈

Abstract 🌸

This document examines the implications of hop-by-hop forwarding, route aggregation, and route filtering on the concept of validation within a BGP Autonomous System (AS) Path.

1. Background 🦋

A lot of brainpower has gone into validating the path to a destination advertised by BGP, and people are still working on it right now 🔥 The goal here is to explain the problems with validating a BGP AS Path, so it can help evaluate schemes that are trying to improve path validation. The first section lays out some of the questions a BGP speaker can ask when it gets an update from a peer that isn't in its own autonomous system (AS). The sections after that look at how those questions play out in real BGP deployments.

The examples in this document are meant to boil deployments down to their most critical parts, so they're easier to understand and think about. In lots of situations the exact path in an example won't matter, but that doesn't cancel out the principles from each example. Some people have said these examples are "red herrings", because they don't show real problems with specific policies. Honestly? These examples are powerful because they're simple 💅 Any topology that contains one of these example topologies as a subtopology will show the same characteristics this document explains. Instead of focusing on one specific topology and then waving it away as a "corner case", this document shows the basic issues with assertions about the AS Path attribute in BGP. Those generalized issues can then be applied to more specific cases. ✨

With everyone being extra about network security right now, the security of the routing information carried by BGP, as described in [RFC4271], is getting a lot of attention. There are techniques for securing the relationship between two devices that swap routing protocol information, such as [BGP-MD5], but they don't guarantee that the information inside the routing protocol is valid or authorized. 😭

The following small internetwork is used throughout this document to look at validity and authorization. It also gives us the definitions we use for the rest of the document 🧚

10.1.1.0/24--(AS65000)---(AS65001)--(AS65002)

Assume a BGP speaker in AS65002 has received an advertisement for 10.1.1.0/24 from a BGP speaker in AS65001, with an AS Path of {65000, 65001}.

1.1. Is the Originating AS Authorized to Advertise Reachability to the Destination?

The most obvious question the receiving BGP speaker can ask about this advertisement is whether the originating AS, which here is AS65000, is authorized to advertise the prefix in the advertisement, which here is 10.1.1.0/24. Whether a BGP speaker that receives a route to 10.1.1.0/24 originating in AS65000 can verify that AS65000 is actually authorized to advertise 10.1.1.0/24 is outside the scope of this document 🙈

1.2. Is the Path Contained in the Advertised Routing Information Valid?

If a BGP speaker gets an advertisement from a peer outside the local autonomous system (AS), the peer sending the update has a path to the destination prefix in that update. More specifically: are the autonomous systems in the internetwork connected in a way that lets the receiver, following the AS Path listed in the BGP update itself, reach the originating AS listed in the received AS Path? In this document, we call that path validation 💖

In the context of this small internetwork, path validation asserts that when a BGP speaker in AS65002 receives an advertisement from a BGP speaker in AS65001 with the AS Path {65000, 65001}, the speaker can assume that AS65001 is attached to the local AS, and that AS65001 is also attached to AS65000.

1.3. Is the Advertisement Authorized?

There are at least three senses in which re-advertising a received advertisement can be authorized in BGP 👑

  • The transmitter is authorized to advertise the specific routing information contained in the route. This treats the routing information as a single, atomic unit, no matter what information the route actually holds. A route to 10.1.1.0/24 and another route to 10.1.0.0/16 count as completely different advertisements of routing information, so an AS may be authorized to advertise 10.1.0.0/16 without regard to whether it's authorized to advertise 10.1.1.0/24, since these are two separate routes. This is called route authorization throughout this document.
  • The transmitter is authorized to advertise the specific reachable destination(s) contained in the route. This treats the routing information as a set of destinations. 10.1.1.0/24 is contained within 10.1.0.0/16, and authorization to advertise the latter implies authorization to advertise the former. This is called reachability authorization throughout this document.
  • The transmitter is authorized to transit traffic to the destinations contained within the route. This ties the concept of the route to what the route is actually used for. If a BGP speaker is advertising reachability to 10.1.1.0/24, it is authorized to transit traffic to all reachable destinations within 10.1.1.0/24 along the advertised path. This is called transit authorization throughout this document.

There is a lot of tension between these three definitions of authorization. Much of this document is built around exploring how these types of authorization relate to each other, and how they may or may not work in different internetworks 🌈 One of the conclusions this document reaches is that route authorization, reachability authorization, and transit authorization are often at odds with each other. Showing that one type of authorization is true does not show that any other type is true. Route authorization is also of questionable value, because the three types of authorization are so intertwined in a routing system. 💀

1.4. Will Traffic Forwarded to an Advertising Speaker Follow the Described AS Path?

If a BGP speaker gets an advertisement from a peer that isn't in the local AS, will traffic forwarded to the peer that sent the update follow the path described in the AS Path? In this document, this is called forwarding consistency 🦋

In terms of the small example internetwork: if a BGP speaker in AS65002 receives an advertisement from a peer in AS65001 for the destination 10.1.1.0/24, with an AS Path of {65000, 65001}, will traffic forwarded to the BGP speaker in AS65001 actually go through routers within AS65001, then AS65000, to reach its destination? 🤔

1.5. Is a Withdrawing Speaker Authorized to Withdraw the Routing Information?

If an advertisement is withdrawn, the withdrawing BGP peer was originally advertising the prefix, or was authorized to advertise it. This assertion is out of the scope of this document 🧚

2. Analysis 🔥

To start, we go over some of the basic concepts of routing, since we need to keep those concepts firmly in place while we look at these questions. After that, four examples are worked through with BGP to show the tension between the various types of authorization in a path vector routing system.

2.1. A Short Analysis of Routing

Routing protocols are designed, in short, to discover a set of loop-free paths to each reachable destination within a network (or internetwork). The loop-free path chosen to reach a specific destination may not be the shortest path, and it may not always be the "best" path (depending on the definition of "best"). But it should always be a loop-free path, otherwise the routing protocol has failed 💅

This tells us what the path in a path vector protocol's routing update is for: the path is there to prove the path is loop free, not to provide any other information. Dijkstra's Sender Policy Framework (SPF) and the Diffusing Update Algorithm (DUAL) both base their loop-free path calculations on the cost of a path. Path vector protocols, such as BGP, prove a path is loop free by carrying a list of the nodes the advertisement itself has traversed. BGP specifically uses an AS Path-based mechanism to prove loop freeness for any given update, so each AS along the path can implement local policy without risking a loop in the routing system caused by competing metrics. 🫶

We need to keep this principle in mind when we think about using the path carried in a path-vector protocol, and about a receiving BGP speaker using it to set policy or gauge the route's security level. ✨

2.2. First Example: Manual Intervention in the Path Choice ✨

okay so let's look at a tiny network first 🌸 (small but mighty):

                   +---(AS65002)---+
   (AS65000)--(AS65001)          (AS65004)--10.1.1.0/24
                   +---(AS65003)---+

A BGP speaker in AS65000 may get an advertisement from a peer saying that 10.1.1.0/24 is reachable along the path {65004, 65002, 65001}. Based on that info, the BGP speaker may forward packets to its peer in AS65001, expecting them to take the path described. BUT inside AS65001, the network administrator may have set up a static route that makes the next hop to 10.1.1.0/24 the edge router with AS65003. 💀

It's useful to note that while [RFC4271] states: "....we assume that a BGP speaker advertises to its peers only those routes that it itself uses...", the definition of the term "use" is rather loose in all known widely deployed BGP implementations. Rather than meaning: "A BGP speaker will only advertise destinations the BGP process on the speaker has installed in the routing table", it generally means: "A BGP speaker will only advertise destinations that the local routing table has a matching route installed for, no matter what process on the local router installed the route". 🙈 A naive reaction might be to just change the BGP specifications and all existing implementations so a BGP speaker will only advertise a route to a peer if the BGP process on the router actually installed the route in the local routing table. This, however, ignores the complex interactions between interior and exterior gateway protocols, which most often run on the same device, and the complexities of route origination. Not it.

Although this is an "extreme" example, since we can hardly claim the information within the routing protocol is actually insufficient, we still find this example instructive in light of the questions outlined in Section 1:

  • Is the AS Path valid? The AS Path the receiving BGP speaker in AS65000 receives from its peer in AS65001, {65004, 65002, 65001), does exist, and is valid. ✅
  • Is the advertisement authorized? Since we have no knowledge of any autonomous system level policy within this network, we have no way of answering this question. We can assume that AS65001 has both route and reachability authorization, but it is difficult to see how transit authorization can be accomplished in this situation. Even if the BGP speaker in AS65000 could verify AS65001 is authorized to transit AS65002 to reach 10.1.1.0/24, this implies nothing about the authorization to transit traffic through the path traffic will actually take, which is through AS65003. 😭
  • Is the AS Path consistent with the forwarding path (does forwarding consistency exist)? No, the advertised AS Path is {65004, 65002, 65001}, while the actual path is {65004, 65003, 65001}. 💔

From this example, we can see forwarding consistency is not possible to validate in a deployed network. Just because a BGP speaker advertises a specific path to reach a given destination, there is no reason to assume traffic forwarded to the speaker will actually follow the path advertised. We can reason this from the nature of packet-forwarding networks: each router along a path makes a completely separate decision about where to forward received traffic. Any router along the path could actually change the path due to network conditions without notifying, in any way, upstream routers. Therefore, at any given time, an upstream router may be forwarding traffic along a path that no longer exists, or is no longer optimal, and downstream routers could be correcting the forwarding decision by placing the traffic on another available path unknown to the upstream router. The chaos is real 🌀

As a corollary, authorizing transit through a specific AS Path is not possible, either. If the source of a specific flow cannot know what path the traffic within that flow will take to reach the destination, then there is no meaningful sense in which downstream routers can authorize the source to use available paths for transiting traffic. 🫶

2.3. Second Example: An Unintended Reachable Destination 🎀

In this internetwork, we assume a single policy: the system administrator of AS65000 would not like the destination 10.1.1.0/24 to be reachable from any autonomous system beyond AS65001. In other words, 10.1.1.0/24 should be reachable within AS65001, but not to autonomous systems connected to AS65001, such as AS65002.

10.1.1.0/24---(AS65000)---(AS65001)---(AS65002)

The system administrator can implement this policy by causing BGP speakers within AS65000 to advertise 10.1.1.0/24 to peers within AS65001 with a signal that the BGP speakers in AS65001 should not readvertise the reachability of this routing information. For example, BGP speakers in AS65000 could advertise the route to 10.1.1.0/24 with the NO_ADVERTISE community attached, as described in [RFC4271]. If the BGP speakers in AS65001 are configured to respond to this community (and we assume they are for the purposes of this document) correctly, they should accept this advertisement, but not readvertise reachability to 10.1.1.0/24 into AS65002. 🦋

However, unknown to the system administrator of AS65000, AS65001 is actually advertising a default route to AS65002 with an AS Path of {65001}, and not a full routing table. If some host within AS65002, then, originates a packet destined to 10.1.1.1, what will happen? The packet will be routed according to the default route from AS65002 into AS65001. Routers within AS65001 will forward the packet along the 10.1.1.0/24 route, eventually forwarding the traffic into AS65000. Oh no 😱

  • Is the AS Path valid? This is a difficult question to answer, since there are actually two different advertisements in the example. From the perspective of the BGP speaker in AS65002 receiving a default route in an advertisement from a peer in AS65001, the AS Path to the default route is valid. However, there is no route to 10.1.1.0/24 for the BGP speaker in AS65002 to examine for validity, so the question appears to be out of scope for this example.
  • Is the AS Path consistent with the forwarding path (is there forwarding consistency)? From the perspective of a BGP speaker in AS65002, traffic forwarded to AS65001 towards a destination within 10.1.1.0/24 is going to actually terminate within AS65001, since that is the entire AS Path for the default route. However, this traffic actually transits AS65001 towards AS65000. Therefore, forwarding consistency does not exist in this example, in which we are dealing with a case of aggregation, and as Section 9.1.4 of [RFC4271], in reference to aggregated routing information, states: "Forwarding along such a route does not guarantee that IP packets will actually traverse only ASes listed in the AS_PATH attribute of the route". 🌈

2.3.1. Advertisement Authorization 💜

Is the advertisement authorized? This example highlights the tension between the three different types of authorization. The three following sections discuss issues with different advertisements AS65001 may send to AS65002.

2.3.1.1. Valid Unauthorized Aggregates 🍓

The first issue that comes up in this example is the case where there is no expectation of authorization for aggregation. The most common example of this is the advertising and accepting of the default route (0/0). This is a common practice, typically done by agreement between the two parties. Obviously, there is not an authorization process for such an advertisement. This advertisement may extend reachability beyond the originator's intention (along the lines of the previous example). It may cause packets to take paths not known by the sender (since the path on 0/0 is simply the advertising AS). It may violate other security constraints. This places limits on the power and applicability of efforts to secure the AS path and AS policies. It does not vitiate the underlying value in such efforts. ✨

2.3.1.2. Owner Aggregation ✨

Okay so, in how IP address allocation works today, an AS might get authorization to advertise something like 10.1.0.0/16, and then it can authorize some other party to use (or own) 10.1.1.0/24, which is a little chunk of that space. This is called a suballocation. 🍰

Here's how it plays out. If AS65001 were authorized to originate 10.1.0.0/16, it could advertise 10.1.0.0/16 towards AS65002, instead of just sending a default route. 🦋 Say there's some kind of authorization mechanism AS65002 can check to confirm AS65001 is allowed to advertise 10.1.0.0/16. Then AS65002 could look at AS65001's authorization to originate 10.1.0.0/16 and assume that, since AS65001 is authorized to advertise 10.1.0.0/16, it's also authorized to transit traffic toward every possible subblock of (every destination within) 10.1.0.0/16. Main character energy, but it's a big assumption! 💅 Let's break it down:

  • AS65002 verifies route authorization by examining the authorization of AS65001 to advertise 10.1.0.0/16.
  • AS65002 assumes destination authorization, that AS65001 has the authorization to advertise every possible subblock of 10.1.0.0/16, because AS65001 is authorized to advertise 10.1.0.0/16.
  • AS65002 assumes transit authorization, that AS65001 has the authorization to transit traffic to every possible subblock of 10.1.0.0/16, because AS65001 is authorized to advertise 10.1.0.0/16.

Honestly, the example makes it super obvious that route authorization does not equal destination or transit authorization. 🙈 AS65001 really does have route authorization to advertise 10.1.0.0/16, but it does not have destination authorization to advertise 10.1.1.0/24, and it doesn't have transit authorization for destinations inside 10.1.1.0/24 either.

The naive fix would be to just say that destination and transit authorization shouldn't be assumed from route authorization. 🤷‍♀️ But it's not that simple, bestie. AS65002 doesn't actually decide to assume those things; they're baked into the way the routing system works. The route itself, within the design of routing, carries those implications. 😭

So why does routing tangle these three types of authorization together? Mostly because AS65002 doesn't have any info about the subblocks that live inside 10.1.0.0/16. There's no way for AS65002 to check destination and transit authorization, because that information gets removed from the system altogether. To actually show destination and transit authorization, the info has to be reinjected into the routing system somehow. 🧚

Take destination authorization on its own. You could imagine a system where AS65001, when it suballocates part of 10.1.0.0/16 to the originator, also has to get permission to keep advertising the original block as an aggregate. Cute idea, but it raises some issues:

  • If the originator didn't agree to AS65001 advertising an aggregate containing 10.1.1.0/24, then AS65001 would be forced to advertise some collection of advertisements that don't contain the suballocated block.
  • If AS65001 actually does get permission to advertise the aggregate, we need some way to give AS65002 information about this authorization for each possible subblock of 10.1.0.0/16.

Basically, either AS65002 has to receive the actual routes for each suballocation of 10.1.0.0/16, or it has to receive some form of authorization letting AS65001 advertise each suballocation of 10.1.0.0/16. 😬 That seems to defeat the whole purpose of aggregation, making routing systems way less scalable than the current design allows. And it still doesn't answer how AS65002 would even know what all the suballocations of 10.1.0.0/16 actually are. A few possible solutions could be:

  • The suballocator must advertise all suballocations. This could potentially expose business relationships and patterns that many large commercial providers don't want exposed, and it degrades the hierarchical nature of suballocation altogether. 💀
  • The IP address space must be reconstructed so that everyone using IP address space will know, based on how the address space is built, which subblocks exist. For instance, the longest allowed subblock could be set at a /24, and authorization must be available for every possible /24 in the address space, either for origination or as part of an aggregate. This sort of solution would be an extreme burden on the routing system. 😩

2.3.1.3. Proxy Aggregation 🌸

It's also possible for AS65001 to have some kind of agreement with AS65002 to aggregate blocks of address space it doesn't own, advertised toward AS65002. This might be done to reduce the burden on BGP speakers within AS65002. This is called proxy aggregation. Proxy aggregation is rare, but it's still useful to look at what happens with agreed-upon proxy aggregation in this situation.

Let's say AS65001 has an advertisement for 10.1.0.0/24 from some unknown source, and it decides to advertise both 10.1.0.0/24 and 10.1.1.0/24 as 10.1.0.0/23 to AS65002. If there's an agreement for AS65001 to advertise proxy aggregates to AS65002, then AS65002 will accept the advertisement regardless of any attached authorization to advertise. 🫣 This may be a security risk for AS65002, but from AS65002's perspective, it might be seen as an acceptable risk when you weigh the trade-offs.

Here's the tea, though. This also affects the policies of AS65000, which originates one of the two routes being aggregated by AS65001. ☕ AS65002 has no way of knowing about that policy, nor of reacting to it, and there's actually no incentive for AS65002 to react to a security threat posed to AS65000, since it doesn't have a direct relationship with AS65000. There doesn't seem to be any immediately available solution to this, other than disallowing proxy aggregation, even between two cooperating autonomous systems. 🚫

2.3.2. Implications 🔮

The core problem is that AS65002 assumes that when AS65001 advertises an authorized route containing 10.1.1.0/24, whether through a valid unauthorized aggregate, an owner aggregated route, or a proxy aggregation, AS65001 also has destination authorization for the subblock 10.1.1.0/24, plus transit authorization for destinations within 10.1.1.0/24. Those are, in fact, invalid assumptions, but they're tied to the way routing actually works. 🥲 So the value of route authorization is pretty questionable, unless there's some way to untie destination and transit authorization from route advertisements, which are deeply intertwined today.

2.4. Third Example: Following a Specific Path 🛤️

This one is a little more complex than the last two, so hold on to your hat! 🎀 Take the following small network. A and D have a mutually agreed-upon policy of not allowing traffic to transit B to reach destinations within 10.1.1.0/25.

10.1.1.0/25--A---B---C---D
             |       |   |
             E-------F---G

Here's what's going on:

  • A advertises 10.1.1.0/25 to B, and 10.1.1.0/24 to E.
  • B advertises 10.1.1.0/25 {B,A} to C.
  • E advertises 10.1.1.0/24 {E,A} to F, filtering 10.1.1.0/25 {E,A} based on some local policy.
  • F advertises 10.1.1.0/24 {F,E,A} to C and to G.
  • C advertises 10.1.1.0/24 {C,F,E,A} to D, filtering 10.1.1.0/25 {B,A} based on some local policy.
  • G advertises 10.1.1.0/24 {G,F,E,A} to D.
  • D chooses 10.1.1.0/24 {C,F,E,A} over 10.1.1.0/24 {G,F,E,A}.

So what path does traffic forwarded to C, destined to hosts within 10.1.1.0/25, actually follow? 🤔

  • D forwards this traffic to C, since its best path is through 10.1.1.0/24 {C,F,E,A}.
  • C forwards this traffic to B, since its best path is through 10.1.1.0/25 {B,A}.
  • B forwards this traffic to A, since its best path is through 10.1.1.0/25 {A}.

Now let's check this result:

  • Is the AS Path valid? Both {G, F, E, A} and {C, F, E, A} are valid AS Paths, so both AS Paths in this example are valid. ✅
  • Is the advertisement authorized? Assuming A is authorized to advertise 10.1.1.0/24, and all the autonomous systems in the example are authorized to readvertise 10.1.1.0/24, the route is authorized. However, C does not have destination or transit authorization to 10.1.1.0/25, since B is the best path from C to 10.1.1.0/25, and D and A have explicit policies not to transit this path. In effect, C doesn't have destination or transit authorization for 10.1.1.0/24, because it contains 10.1.1.0/25. 😵‍💫
  • Is the AS Path consistent with the forwarding path (is there forwarding consistency)? While C is advertising the AS Path {C, F, E, A} to D to reach destinations within 10.1.1.0/24, it's actually forwarding along a different path to some destinations within this advertisement. Forwarding consistency does not exist within this internetwork. 💔

In this example, A assumes that D will receive both the advertisement for 10.1.1.0/24 and the advertisement for 10.1.1.0/25, and will be able to use the included AS Path to enforce their mutually agreed-upon policy not to transit B. 🥺 But the information about 10.1.1.0/25 is removed from the routing system by policies that are outside the knowledge or control of A or D. The information that remains in the routing system implies D may correctly route to destinations within 10.1.1.0/25 through C, since 10.1.1.0/25 is contained within 10.1.1.0/24, which C is legally advertising.

The tension between route authorization, destination authorization, and transit authorization shows up really clearly in this more complex example. 🌈 Route authorization implies destination and transit authorization in routing, but in this example, route authorization doesn't include destination or prefix authorization. That's the whole drama, periodt! 💅

2.5. Fourth Example: Interior and Exterior Paths Mismatch 🧩

Okay bestie, this is the most complex example in the whole doc 😭🫶. Ngl, some people would say this setup is just a misconfiguration 💀, but we picked it because it's SIMPLE and it still shows how interior and exterior gateway protocols get tangled up inside one autonomous system 🕸️. Route reflectors (especially in a hierarchy) cause forwarding inconsistency too, but they're way messier than this tiny little setup.

    +-----F(9)---------------G(3)--------+
    |                         |          |
    |                  +------+          |
    |                  |                 |
    |        +---C(2)--+                 |
    |        |         |                 |
   A(1)-----B(2)       +----------------E(5)--10.1.1.0/24
    |        |         |                 |
    |        +---D(2)--+                 |
    |                                    |
    +------------------H(6)--J(7)--K(8)--+

Here's the vibe with the diagram 🎀: each router has a label, and the AS it lives in is in parentheses right after the router name. Now here's what each router thinks its best path to 10.1.1.0/24 is 👀:

  • Router E 💜 is using its local (intra-AS) path.
  • Router C 🌸 is using the path through AS3.
  • Router D is using the path through Router E.
  • Router B is using the path through Router E.

But wait, look closer at Router B 🫣. It likes the path it learned from Router E, right? Cool. BUT that path says the next hop is Router E itself. Here's the plot twist: Router B's best route to Router E (as decided by the interior routing protocol) actually goes through Router C 😳. So Router B tells Router A the path is {2, 5}, yet the traffic really takes {2, 3, 5} once Router B gets it. Not okay 💅.

Now the AS1 admin 🕵️‍♀️ has decided there's an attacker in AS3, so they set a policy on router A to avoid any route with AS3 in the AS Path. With that rule in place, router A tosses the path learned from AS9. It's left with two paths, one from AS2 (B) and one from AS6, and it picks {2, 5} through AS2 (B) as the best. But here's the tea ☕: router A doesn't know that AS2 (B) is also connected to AS3, and it's transiting traffic to AS5 via {2, 3, 5}. Main character energy for the attacker, honestly 🙈.

Okay, back to our three questions 🎀:

  • Is the AS Path valid? The AS Path {2, 3, 5} is a valid AS Path.
  • Is the route authorized? Assuming each AS along the path is authorized to originate, or readvertise, 10.1.1.0/24, the route is authorized. Destination authorization is also clear here, since 10.1.1.0/24 is the single destination throughout the example. Transit authorization is trickier, though, because the traffic doesn't actually flow along the AS Path in the routing advertisement. It's impossible to claim the AS Path {2,3,5} is valid from either the route originator or the traffic originator, since that AS Path is not the one advertised. Basically, Router E assumes transit authorization from route authorization, even though there's no way to determine that AS3 is actually authorized to transit traffic to 10.1.1.0/24 😤.
  • Is the AS Path consistent with the forwarding path (is there forwarding consistency)? The advertised AS Path is {2, 5}, while the traffic forwarded to the destination actually transits {2, 3, 5}. Forwarding is not consistent in this example 💀.

3. Summary ✨

The examples in this doc are not the only ones where forwarding doesn't match the advertised AS Path 🫶. [ROUTINGLOGIC] has some more examples too. And [ASTRACEROUTE] is a super interesting read on the real-world impact of this mismatch, especially when you're trying to trace where packets actually go across a big internetwork running BGP as an exterior gateway protocol 🔍.

Routing is SO intertwined with route authorization, destination authorization, and transit authorization 💞. If a BGP speaker is authorized to advertise a specific route, routing assumes it's also authorized to advertise every possible subblock within the destination prefix, and that the advertiser is authorized to transit packets to every destination within the route. Look at these examples and you'll see route authorization doesn't actually equal destination authorization or transit authorization 😭, which makes you question how much route authorization is even worth 🙃.

There are no easy or obviously scalable solutions to this problem 💔.

4. Acknowledgements 🙌

Huge thank-yous to Steve Kent for his contributions and comments on this document 🫶. We also want to thank Joel Halpern for clarifying many sections of the document, including extra text in the critical parts 🧚.

5. Security Considerations 🔐

This document does not propose any new extensions or additions to existing or proposed protocols, and so does not impact the security of any protocol 🛡️.

6. Informative References 📚

[ASTRACEROUTE] Feamster, N. and H. Balakrishnan, "Towards an Accurate
               ASLevel Traceroute Tool", SIGCOMM ACM SIGCOMM, 2003.

[BGP-MD5]      Heffernan, A., "Protection of BGP Sessions via the TCP
               MD5 Signature Option", RFC 2385, August 1998.

[RFC4271]      Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
               Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
               2006.

[ROUTINGLOGIC] Feamster, N. and H. Balakrishnan, "Towards a Logic for
               Wide Area Routing", SIGCOMM ACM SIGCOMM Worshop on
               Future Directions in Network Architecture, Germany,
               August 2003.

[SOBGP]        White, R., "Architecture and Deployment Considerations
               for Secure Origin BGP (soBGP)", Work in Progress.

Authors' Addresses 💌

Russ White
Cisco Systems

EMail: riw@cisco.com


Bora Akyol
Cisco Systems

EMail: bora@cisco.com

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.

Okay, legal bit, but it matters 🙈. This document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE 📜.

Intellectual Property 🪪

The IETF doesn't take a position on whether any Intellectual Property Rights or other rights that might be claimed for the technology in this document are valid or in scope, or whether any license under those rights might be available. It also doesn't say it has made any independent effort to find such rights. Info on how rights work for RFC documents is in BCP 78 and BCP 79 💅.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users to use these proprietary rights can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔗.

The IETF invites anyone interested to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💖.

📦 where this page comes from