BGP Route Selection: Origin Validation vs. Best Path

Understanding BGP Decision Making

The Border Gateway Protocol (BGP) is the routing protocol of the internet. Its primary function is to exchange routing and reachability information between autonomous systems (ASes). While often discussed in terms of finding the 'best path' for traffic, BGP's internal decision-making process is more nuanced. Two critical, yet distinct, stages are involved: origin validation and best path selection. Misunderstanding their separation can lead to routing instability and security vulnerabilities.

The common misconception is that BGP's decision-making process is a monolithic event where all factors are considered simultaneously. In reality, BGP operates in a sequential manner. First, a route must pass certain validation checks. Only after it has been validated does it enter the complex process of best path selection. This sequential nature is crucial for both network stability and security. Origin validation acts as a gatekeeper, ensuring that only legitimate routes are even considered for the routing table.

This article dives into the distinction between these two fundamental BGP processes, drawing from the insights provided by the 'Protocol in Code' series. We will explore what origin validation entails, why it precedes best path selection, and the implications of this separation for network operators and security professionals.

Origin Validation: The First Line of Defense

Origin validation is a security mechanism designed to prevent IP address spoofing and route hijacking. It ensures that an AS announcing a prefix is authorized to do so. The primary technology behind this is Resource Public Key Infrastructure (RPKI). RPKI allows Regional Internet Registries (RIRs) to cryptographically sign their allocations of IP address blocks. Network operators can then create Route Origin Authorizations (ROAs) that specify which ASNs are permitted to originate routes for their allocated prefixes.

When a BGP router receives a route announcement, it first queries its RPKI cache to validate the origin AS. This validation process results in one of three states:

• Valid: The announced prefix is covered by a ROA, and the originating ASN matches the ROA.
• Invalid: The announced prefix is covered by a ROA, but the originating ASN does not match the ROA, or the prefix is not covered by any ROA.
• Unknown: The RPKI cache does not have information about the announced prefix.

A router configured for strict origin validation will discard any routes that are marked as 'Invalid'. Routes marked 'Unknown' are typically treated as 'Valid' by default, though this behavior can be configured. This initial step is paramount. If a route fails origin validation, it is dropped immediately. It never even makes it to the 'consideration' phase for best path selection. This is analogous to a security checkpoint at an airport. If your documents are not in order, you are not allowed to proceed to the boarding gate, regardless of how desirable your seat might be.

Best Path Selection: The Complex Algorithm

Once a route has successfully passed origin validation (i.e., it is 'Valid' or 'Unknown' and not explicitly discarded), it then enters the Best Path Selection Algorithm (BPSA). This is a multi-attribute decision process that aims to find the single best route to a destination prefix from the various paths learned via BGP. The BPSA considers a series of attributes, and the path that ranks highest according to these attributes is chosen.

The typical order of BGP attributes considered in the BPSA is:

1. Weight: A Cisco-specific attribute that prefers locally configured routes.
2. Local Preference: Used within an AS to prefer certain exit points. Higher is better.
3. S-BIT (if applicable): A flag indicating if the route was originated by the local system.
4. AS_PATH Length: Shorter AS paths are preferred.
5. Origin Type: IGP (i) is preferred over EGP (e), which is preferred over Incomplete (?).
6. Originator ID: Used in confederations.
7. MED (Multi-Exit Discriminator): Used to influence traffic entering an AS from external peers. Lower is generally better.
8. eBGP over iBGP: Prefer routes learned from eBGP peers over iBGP peers.
9. IGP Metric to Peer: Prefer the route whose next-hop is closest according to the IGP.
10. Oldest iBGP path: If multiple paths have the same best attributes, prefer the one learned first.
11. Router ID: Prefer the path from the router with the lowest Router ID.
12. Peer IP Address: Prefer the path from the peer with the lowest IP address.

It's critical to understand that the BPSA operates on routes that have already passed origin validation. A route that is perfectly valid according to the BPSA—perhaps it has the shortest AS_PATH or highest local preference—will still be discarded if it fails origin validation. Conversely, a route that passes origin validation might still be suboptimal according to the BPSA, and thus not chosen as the best path.

Import Policy: A Pre-Validation Filter

Adding another layer to this sequence is the concept of import policy, often implemented using route-maps or prefix-lists. These policies are applied *before* origin validation and often before the route is even processed by the BGP state machine for full validation. Import policies allow network administrators to filter incoming routes based on criteria such as source IP address, AS path, community tags, or prefix length.

A route might be perfectly valid according to RPKI and have desirable BGP attributes, but an administrator might still choose to filter it out based on policy. For example, an organization might have a strict policy that only allows routes originating from specific known ASNs, or routes that carry certain community tags indicating their purpose. If a route fails this import policy, it is discarded at this very early stage, never reaching the RPKI validator or the BPSA.