If you run BGP in your network, you need to think about BGP security. It might not seem like it’s important if you’re not a provider, but two points to consider:
- First, if you’re connected to the Internet, making certain your little corner of the Internet is secure is important
- Second, no matter where you use BGP in your network
Or maybe you just want to learn something more about providers handle BGP security in their networks. Whether you use BGP or not, the Routing Resilience Manifesto is a good place to start implementing (or just learning) BGP security. If every provider actually implements these recommendation, many of the security issues we’ve seen in the Internet recently, like this one. Let’s spend a few moments looking at one of their recommendations in a little detail to get a sense of what this manifesto effort is all about. The first is prevent propagation of incorrect routing information. More detail is provided:
Most important is to secure inbound routing advertisements, particularly from customer networks, through the use of explicit prefix-level filters or equivalent mechanisms. Secondarily, AS-path filters might be used to require that the customer network be explicit about which Autonomous Systems (ASes) are downstream of that customer. Alternately, AS-path filters that block announcements by customers of ASes with which the provider has a settlement-free relationship can prevent some types of routing “leaks”. Filtering customer BGP announcements by AS-path filters alone is insufficient to prevent catastrophic routing problems at a systemic level.
The primary point here is to make certain the routes your customers are advertising to you are, in reality, what they should be advertising to you. To get to this point, you have to know, for certain, which IP address blocks the customer is actually allowed to own. There are several ways you could go about this — for instance, you could ensure that the advertised routes are contained in any contract with the customer, and, as a provider, that you go back to the issuing registry to make certain the company you’re signing a contract with actually owns the address space in question. This is a lot of work, which is why there are ideas like the origin authentication in play. An alternative is to require each customer insert their routes into an IRR so the provider can go back and check there.
The point, either way, is to put the policies needed to implement security around customer/provider connections into the public view, so they can be effectively enforced by providers multiple hops away, and to build a security trust relationship between providers. One of the points we often forget about security is that you can’t enforce what you don’t know — security that hides the intent is as impossible to implement as security that hides the algorithms and code implementing the security.
How would you implement such a policy? Note the detailed statement above states the policy can’t be implemented effectively with just AS Path, or AS level, filters. Not only must you filter based on the AS path, but also the actual prefixes you expect the customer to advertise. These types of filters will also prevent “valley” routing paths, where a competing provider’s routes are advertised to their customer, and then readvertised back into your network, making the customer a transit path.
What does this mean, as an example, for an enterprise network using BGP in the network core? Policies similar to a provider should be implemented along the BGP core. An internal registry of addresses should be maintained, and filters set up to prevent “customers,” whether they are business units, or just different sections of the network, from becoming a transit.
The routing resilience manifesto is a gold mine in the world of routing security.