BGP Filtering at the Edge

BGP Filtering at the Edge NetworkWorld.com Community
When you work with IGPs, you tend to think of routing holistically. That’s because IGPs are designed to run under a single administrative authority and so assume that all peers in the routing domain can be trusted.
BGP, on the other hand, is designed to be run between routers in different administrative domains and therefore between untrusted peers. As a result BGP requires that you think differently about routing.
First, unlike an IGP in which you think about the entire routing domain, each external BGP (EBGP) session must be considered separately. That means security, prefix filtering, and routing policy must be considered separately for each external peer.
Second, for each EBGP session you consider incoming and outgoing route advertisements separately. It might be that you need BGP to advertise prefixes, but do not need to receive any BGP routes. Or you might need to receive routes from BGP but do not need to advertise any. Or you might need BGP for both incoming and outgoing advertisements.
So the first consideration is: Do you need BGP at all? In most cases you only need BGP if you can answer “yes” to all four of these questions:
(1) Are you connecting to another routing domain?
(2) Are you connecting to a domain under a separate administrative authority?
(3) Is your domain multihomed?
(4) Are routing policies required to influence the choice among multiple outgoing routes to the same destination or to influence incoming traffic?
Let’s consider incoming routes first: You’re multihomed, and you need more precision in route selection than you can get from simple static and default routes configured at the edge and redistributed into your IGP. (And remember, static routes and BGP are your only wise choices for routing beyond the edge. As I said in a previous post, never, ever run an IGP with a router outside of your administrative control.) Or, you are accepting so many different prefixes that creating a prefix-list to accept the prefixes you expect and reject everything else is impractical – if you could write the acceptable prefixes in a prefix list, you could write them as static routes and avoid BGP altogether.
When you must run EBGP, you need to be careful as mice in accepting advertisements from that untrusted peer. Malicious threats do exist, but the greatest risk you face is from someone in another domain committing a configuration error that sends unintended, unwanted, and potentially damaging information into your domain.
Your first line of defense is a bogon filter. Bogons are prefixes widely understood to be bogus outside of a single domain: Things like RFC1918 addresses (10.0.0.0 - 10.255.255.255, 172.16.0.0 - 172.31.255.255, and 192.168.0.0 - 192.168.255.255), loopback addresses (127.0.0.0 - 127.255.255.255), and multicast, class E, and broadcast addresses (224.0.0.0 - 255.255.255.255).
But the bogons I’ve listed here are just the most common of the prefixes reserved by the IANA for special use, and called martians. There less-well-known martians (a complete list can be found here), and there are bogons that are not martians at all, but are blocks of addresses not currently allocated by the IANA to any RIR. Hence the innocent-looking 74.124.176.0/20, for instance, is a bogon.
A good bogon filter, built with a prefix-list that denies a list of bogons, is likely to be 50 – 100 terms long or longer. One of the best sources for the bogon list in several formats, updated daily, is available from CompleteWhois; there are also sites like the one from Team Cymru that conveniently convert the lists into manageable configurations for IOS and JUNOS.
Bogon lists change regularly, though, so you should be prepared for someone on your operations team to update your bogon filter at least weekly. Scripting is a big help here.
There are further measures you can use to bolster this first line of defense:
Use a command or filter that removes all private AS numbers (64512 – 65535) from the AS_PATH of all incoming NLRI, in case your peering neighbor is using one and forgets to filter it out of his outgoing routes.
Use an AS_PATH filter to insure that the AS number of the external peer is always the first number on the AS_PATH list. This gives you an extra safeguard against spoofed prefixes getting into your domain.
Use a prefix limit filter that accepts a number of prefixes just a little larger than what you expect from the external peer. This protects you from a misconfiguration that could send a flood on unwanted prefixes into your network.

Next let’s consider outgoing routes. Some ISPs might refuse to accept incoming EBGP advertisements without good justification, to protect themselves for the same reasons I’ve cited here. For most stub (that is, non-transit) autonomous systems having your provider or providers configure static routes to your prefixes on their side is just as good as advertising the prefixes to them via EBGP. If you need to add another prefix occasionally, a call or e-mail to your service providers is usually no more work than adding the necessary BGP and filtering configs to advertise it. And verifying that your ISP is correctly advertising your statically configured prefixes is easily done by checking a few publicly accessible route servers.
But if you do advertise prefixes to external BGP peers, be a good neighbor and set policies which insure that you only advertise what you intend. First, just as you never redistribute BGP routes into your IGP, never redistribute IGP routes into BGP. Either statically configure the prefixes you want to advertise and redistribute those into BGP, or use (in IOS, anyway) the BGP network command to specify the prefixes to be advertised. In either case, remember to point these to a null interface so that your valid IGP routes pick up incoming packets when they arrive at the router, and the packets are discarded when an IGP route is unavailable.
Next, if you run a stub domain, add a prefix filter that allows only the prefixes you want to advertise, and deny everything else. In most cases this is good enough to protect yourself and your external peers from mistaken advertisement of unintended prefixes. (One of the big hazards for a multihomed stub network is inadvertently causing your domain to be viewed—and possibly used—as a transit domain by advertising an incorrect prefix.)
For ISPs and other domains providing transit services, edge filtering is far more challenging. By definition, a transit provider is accepting prefixes from some peers and readvertising those prefixes to other peers. For most providers what prefixes are accepted, and what prefixes are advertised, varies tremendously among the various external connections.
Such domains take full Internet routes from one or more upstream providers, plus customer routes from other providers with whom they have peering agreements, plus their own customers’ routes, plus their own internal routes. Out of all these, some customer prefixes are advertised upstream and to peering partners, other customer prefixes are part of the provider’s aggregate and therefore are not advertised. The provider advertises full Internet routes to some customers, partial routes (usually the prefixes of only the provider’s other customers and perhaps its peering partners’ customers) to other customers, and nothing at all to yet other customers.
If you’re running a transit domain you certainly don’t want to create individual policy and filtering configurations for every external peer. So how do you get control of the complexity in such a network?
Communities!
The BGP community attribute is one of the most powerful tools available to you for scaling complex BGP routing policies. You define a set of communities with meanings that can be as general or as specific as you want, and then assign one or more of those defined communities to prefixes as they are received. Then, instead of creating outgoing filters for individual prefixes you filter on your communities.
So for a given external peer you might have a policy that allows public Internet routes, all prefixes from all peering partners, and all customer prefixes; for another external peer you might allow all prefixes from a defined subset of your own customers, and nothing else.
In addition to community-based outgoing filters, you should use the same bogon filter that you created for incoming prefixes on your outgoing prefixes. Just as the bogon filter protects you from configuration mistakes in your neighboring domains, it protects your neighboring domains from configuration mistakes you might make.
When running BGP remember that it is important not only to protect your own network, it’s important to protect your neighbors’ networks too.