No, not that kind. 🙂
BGP security is a vexed topic — people have been working in this area for over 20 years with some effect, but we continuously find new problems to address.
I’ve been reading a paper called BGP Communities: Even more Worms in the Routing Can [PDF 814 KB], which analyses some of the security problems caused by current BGP community usage in the ‘net’. The point I want to discuss in this post is not the problem discussed in the paper, but rather some of the larger problems facing security in routing.
Assume there is some traffic flow passing from 101::47/64 and 100::46/64 in this network. AS65003 has helpfully set up community string-based policies that allow a peer to advertise a route with a specified AS Path prepend. In this case, AS65003 receives a route with 3:65004x to prepend the route advertised towards 65004 with x number of additional AS Path entries, and 3:65005x to prepend the route advertised towards 65005 with x number of additional AS Path entries.
Assuming community strings set by AS65002 are carried with the 100::46/64 route through the rest of the network, AS65002 can:
- Advertise 100::/46 towards AS65003 with 3:650045, causing the route received at AS65006 from AS65004 to have a longer AS Path than the route received through AS65005, causing the traffic to flow through AS65005.
- Advertise 100::/46 towards AS65003 with 3:650055, causing the route received at AS65006 from AS65005 to have a longer AS Path than the route received through AS65004, causing the traffic to flow through AS65004.
A lot of abuse is possible because of this situation. For instance, AS65002 might know the cost of the link between AS65006 and AS65004 is very expensive, so directing large amounts of traffic across that link will cause financial harm to AS65004 or AS65006. A malicious actor at AS65002 could also determine it can overwhelm this link, causing a sort of denial of service against anyone connected to AS65004 or AS65006.
The potential problem, then, is real. The problem is, however, how do we solve this?
The most obvious way is to block communities from being transmitted beyond one hop past the point in the network where they are set. There are, however, two problems with this solution.
First, how can anyone tell which AS set a community on a route? There is no originator code in the community string, and there’s no particular way to protect this kind of information from being forged or modified short of carrying a cryptographic hash in the update — which is probably not going to be acceptable from a performance perspective.
But the technical problem here is just the tip of the iceberg. Even if we could determine who modified the route to include the community, there is no particular way for anyone receiving the community to determine the originator’s intent.
AS65002 may well install some system which measures, in near-real-time, the delay across multiple paths to determine which performs the best. Such a system could be programmed with the correct community strings to impact traffic, and then left to run some sort of machine-learning process to figure out how to mark routes to improve performance. If the operator at AS65002 does not realize the cost of the AS65004->AS65006 link is prohibitive, any sort of financial burden imposed by this system could be an unintended, rather than an intended, consequence.
This, it turns out, is often the problem with security. It might be that a person is bypassing building security to save a life, or it could be they are doing so to steal corporate secrets. There is simply no way to know without meeting the person in question, listening to their reasoning, and allowing a human to decide which course of action is appropriate.
In the case of BGP, we’re dealing with ‘spooky action at a distance’. The source of the problem is several steps removed from the result of the problem; there’s no clear way to connect the two, and there’s no clear way to resolve the problem, other than ‘picking up the phone’, even if one of these operators can figure out what is going on.
The problem of intent is what RFC 3514’s evil bit is poking a bit of fun at — if we only knew the attacker’s intent, we could often figure out what to actually do. Not knowing intent, however, puts a major crimp in many of the best-laid security plans.
Russ White is a Network Architect at Juniper Networks.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.