It seems that the discussion about route leaks and securing BGP continues. Here, I’d like to quickly explore the issues related to the distinction between routing protocols, routing policies, routing and packet forwarding, and look at why securing the routing protocol does not necessarily ensure that you have secured packet forwarding.
One view is that route leaks are not necessarily instances of deliberate attempts to lie in routing, and that if one secures the operation of BGP as a protocol then the inadvertent leak of routing information is not necessarily an instance of the protocol itself being misused. The corollary of this perspective is that if one wanted to include mechanisms that would be capable of detecting route leaks within the scope of the operation of the protocol then the protocol itself may need to be equipped with additional capabilities.
The other view I hear is that in attempting to “secure routing” the desired endpoint is a security framework where routing information that conforms with some notion of “intent” would be verifiable by any receiver of the information, while routing information that does not match this “intent” should be readily detectable as such. The corollary from this perspective is that securing the origination of a route, and securing the AS Path in a manner that a receiver of a route can validate that the routing information has been propagated through the network using the same inter-AS path as that represented in the AS Path attribute of the BGP update is simply not enough. From this perspective the concept of a “secure routing protocol” needs to be in a position to encompass the concept of “intent” and be able to detect “leaks” in the same manner as being able to detect various forms of unauthorized manipulation of routing updates.
I suspect that the issue is a little deeper than this, and the basic motivation in attempting to secure BGP is not to secure BGP as a routing protocol. The motivation in attempting to secure the operation of the routing protocol is to prevent packets being directed to places other than their legitimate destination, and to the extent possible, to prevent packets being directed along unauthorized detours on their path. In other words, the actual motivation to secure BGP is to secure the forwarding paths used to reach destinations in the Internet, and an implicit assumption that is often made is to assume that the AS Path in a route represents the forwarding path in the network. Indeed this is very often the case, and the propagation of routes in one direction via the routing protocol at the level of the control plane leads to the creation of forwarding paths in the opposite direction in the network’s data plane. So, goes the line of reasoning, if you secure the AS Path then you have in fact managed to secure the forwarding path.
But routing is not always quite so straightforward. I’d like to look at the following topology to expose some aspects of this
A, B, C and D are all AS’s. A announces its routes to C and B. The relationship between A and B is constrained by A, who does not want to have B act as a transit to reach A, so A marks the routes it sends to B as “NO EXPORT”, thereby preventing B for readvertising these routes its learned from A to its neighbours C and D. C is also connected to B, and has no such constraint, so C announces A’s routes to B, with the AS Path (C, A).
What does B announce to D?
Now B’s preferred route is via its direct peering with A, but B is prevented in re-advertising this route to D because of the NO EXPORT attribute that A has marked on its route.
B is also aware of a second route to A, via AS C. In theory it is feasible that B could announce this route to D, with the AS Path <B C A>, as its certainly the case that C has placed no restrictions on this route’s redistribution. But in the case the announcement would be inconsistent with the forwarding path, as any packets B has that are destined for A pass along B’s preferred path, namely the direct connection to AS A.
The other option for B is not to readvertise A’s routes at all, given that the route that has been preferred by B has been marked as NO EXPORT. Again this feels to be a somewhat uncomfortable answer as now it appears that B is withholding information from D. In this case D will see A’s routes via the path (B C A) whenever the BGP session between A and B is down, and not otherwise. And it is this option that is BGP’s default behaviour. What BGP readvertises is its selected best path. If the NO EXPORT path is the locally selected best path then the path will not be re-advertised to any peers.
Now what happens if D decides to install a default route pointing to B? Then even though A has marked its route as NO EXPORT, and probably intended that B should not act as a transit network and readvertise its routes to A to third parties, B can still act as a transit, and D can still reach A via B.
The AS Path attribute in BGP is not necessarily the same as the path of ASs used to forward a packet to its destination. All that BGP claims about the AS Path is that it can be used for loop detection (BGP speakers should discard an incoming BGP Update message if its own AS is listed in the AS Path attribute of the received BGP route) and as a default route metric (BGP speakers should prefer routes with shorter AS Path lengths, all other things being equal). BGP does not specifically claim that in all cases the AS Path in a BGP route necessarily correspond to the sequence of traversed AS’s when
