Introducing Routing Security

ISPs connect their networks to each other and exchange routing information using the BGP protocol. As the importance of the Internet has grown, the quality and security of Internet routing have become critical.

This Day One Book began as a description of how to implement route validation with RPKI, in order to make it easier for you to deploy by providing tested recipes. But once we started writing about RPKI we found that routing policy in ISP networks is far more extensive than RPKI alone. Thus the scope of this book goes beyond RPKI; it can also help you set up routing policies for all routes that you may accept into your network.

Whether it is threatened by distributed denial of service (DDoS) attacks, prefix hijacks, or ‘just’ unintentional route leaks, your network needs to deliver stability and reliable reachability to the Internet. Most routing incidents are unintentional and due to configuration mistakes, and unfortunately, all network engineers suffer from the fat finger syndrome every now and then! You should consider implementing routing security not only to protect your own network, but perhaps, even more so, to help others protect theirs.

Traditionally, firewalls and IDS/IPS systems are deployed to secure the network, acting on traffic that arrives from the Internet. This means the ‘bad traffic’ has already reached your network before you can reject it and the ‘bad guys’ are communicating with your servers before you can stop them. Extra investments may be needed to filter the clean traffic from the bad traffic.

When you leverage routing security, your network cannot fully communicate with ‘bad actors’ in the first place, thus making securely serving your customers easier and more financially sustainable. The sooner you stop the threat, the better. By deploying the correct methods you may not stop these threats from reaching your network, but you can at least prevent your network from reaching an invalid prefix, making it impossible to establish full two-way communication. So, implementing routing security will make it harder for threats to propagate.

This book talks a lot about the configuration of the BGP-speaking routers that form the edge of a DFZ network. They accept routes across BGP sessions with customers, transit providers, and peers. They also announce routes originating from your network and your customers’ networks. A route advertisement consists, among other things, of a combination of prefix, prefix length, origin AS (autonomous system), and AS path. Routing security aims to reduce the number of potentially invalid announcements that your network accepts by actively rejecting invalid route announcements, and by ensuring you only announce the correct prefixes yourself.

This book collects some of the best current practices for deploying routing security. You can greatly improve the stability and security of your network, and perhaps more importantly the stability and quality of the Internet, by using them.

Filtering and Rejecting Routes is Good!

One of the first concerns that comes to mind when thinking about filtering and rejecting BGP routes is: if I reject a route, surely my network will not be able to reach the whole Internet anymore?! While this could be true, rejecting invalid routes is actually a good thing! Don’t think of it as making part of the Internet unreachable. Instead, consider that leaving out clearly invalid routes from your routing table means that you can make your network immune to (probably unintentional) incorrect route announcements, as well as from (intentional) IP address hijacks.

Another way to think about it is that many of the invalid routes you will reject are accidental announcements (mostly typos!) and rejecting them actually keeps the intended destination reachable, instead of making the unintended destination unreachable. In this case, rejecting the route actually guarantees reachability! And as for the intentional prefix hijacks – it is obvious that you do not wish to accept these in the first place. Therefore, the only option is to reject invalid routes and make your routing table stable and secure.

As an example, say you received a route for a /16 from your transit provider, and a peer is sending you a single /24 that falls in that /16. If this is a legitimate route advertisement and your policies would accept it, you will send the traffic to that peer instead of to the transit, which may be your intention. However, if the route is a mistake or a hijack, then accepting it means that you actually make the correct /24 unreachable by accepting that route! So, rejecting routes does not automatically mean making parts of the Internet unreachable at all.

When deploying RPKI, many network administrators decide to accept RPKI invalid routes regardless, but with a lower local preference. This does absolutely nothing to make the routing table more secure: if the invalid route is more specific to the correct route it will always win. Such is the nature of BGP. The only way to correctly implement RPKI is by rejecting invalid routes.

Deploying routing security isn’t a single checkbox solution. Instead, it is a collection of routing policies, filters, and external sources such as ROA and RPKI validation tools. Routing policies are a method of influencing the default behavior of a routing protocol. In this case you are trying to influence the default behavior of BGP.

Beside the policies, which contain static or semi-static filters, routing security relies on external sources of information, for example those offered by the Regional Internet Registries (RIRs). In cases where RIR tools are mentioned, this book uses RIPE (www.ripe.net) as an example. Obviously, there are other RIRs (https://en.wikipedia.org/wiki/Regional_Internet_registry) who all have more or less the same databases and tools available. ROA and RPKI validation sources are typical examples of external sources that are leveraged in this book.

Internet Routing Registries

Routing information is stored in Internet Routing Registries (IRRs). Each of the RIRs offers their own IRR. In addition, there are third-party IRRs, some are commercial, and others are available free of charge. As you receive an IP address allocation from your RIR, you can create a route object in an IRR in order to ‘connect’ your IP address allocation to your AS number.

But, you guessed it, there is a problem. Even though the IRRs are pretty reliable, not all of the data they contain is guaranteed to be correct. In some IRRs you can create objects without checks of any kind to make sure the information is correct.

Unfortunately, in many cases the IRRs still provide the best data, even though that data may not be totally correct. In the majority of cases the data is good enough and it is better than nothing. Therefore, we still use IRR data as needed, but will use more reliable information when and if it is available.

Manually filtering a few downstream customers or peers with strict filters may be trivial, but filtering hundreds or thousands of customers whose prefix list changes by a handful of routes twice a week isn’t. Especially if you are using IRR sources to build filters, it becomes very time consuming. So we will not touch on manual IRR filtering in the next chapters, but you will find some tips and tricks on how it’s done using scripts in the Appendix.

RPKI

There are hundreds of thousands of route announcements on the Internet today and the magic million is not far away. Many of these announcements are invalid. The most common routing error seen is the accidental route leak or the mis-origination of a prefix, meaning someone unintentionally announces an IP prefix that they are not the holder of, or they advertise a more specific route without a valid routing object in a RIR database. These errors would cause BGP routers to choose a route that is not intended as it does not lead to the network of the rightful owner of the IP space. As a (partial) answer to this problem, RPKI offers BGP origin validation. The question it tries to answer is: “Is this particular route announcement authorized by the legitimate holder of the address space?”

It should be noted that RPKI does not validate the entire AS path. It will only tell you if the originating AS is allowed to advertise that specific prefix. As of this writing, there is no good way to validate the entire AS path. Work is being done in IETF to get a mechanism in place to solve this issue, and those drafts can be found here: https://datatracker.ietf.org/doc/draft-ietf-grow-rpki-as-cones/ and here: https://tools.ietf.org/ html/draft-azimov-sidrops-aspa-verification-01.

RPKI allows network operators to create statements about the route announcements they authorize that can be cryptographically validated with the prefixes they hold. These statements are called route origin authorizations (ROAs). A ROA states which AS is authorized to originate a certain IP address prefix. In addition, it can determine the maximum length of the prefix the AS is authorized to advertise. Based on this information, other network operators can make routing decisions.

Using the RPKI system fully requires action on two parts:

1. The legitimate holder of an IP prefix creates a certificate, or ROA, stating which ASs their prefixes will be advertised (originated) from and the maximum allowed prefix length.

   Note

   Only the owner of the IP address allocation can create a ROA for this allocation. This is more reliable than IRR data.

2. Other network operators can set their routing policies based on the RPKI validity of route announcements when comparing them to the ROAs that were created. These are the routing policies that would ultimately reject invalid announcements.

When it comes to Step 1 above (create ROAs for your own IP allocations), you turn to the web portal of your RIR. For purposes of this book that is the RIPE NCC LIR Portal, where you can easily create your ROAs, and which offers an easy-to-use method of showing your current BGP announcements and confirming whether these are the exact announcements for which you wish to create an ROA. Confirming this choice, and publishing the resulting ROAs, is all you have to do.

If you have not yet created ROAs that cover your IP space, then do so now. Creating ROAs for your IP space means that other networks will not be able to hijack your IP prefixes any more – or more precisely, that those networks which have implemented RPKI will reject these hijacks.

For Step 2 (installing and running a validator that will check the ROAs of other networks), just keep reading and we’ll pull you through!

The RPKI is a public key infrastructure, and any party can choose to set up a Certicate Authority (CA) and host it on their own servers. In order to make it easy to start out with RPKI, the RIRs offer readily hosted CAs for IP space that belongs to their members. The ROAs are stored on the CAs, trust anchors, run by the RIRs. A ROA is a plain text file containing encrypted information and is downloaded from the trust anchor into a validator, which runs in your own network. The validator then talks to your routers so they can make routing policy decisions based on the RPKI information received from the validator.

When a route is RPKI invalid, it means that the advertised route (the IP prefix, the maximum length of the prefix, and the autonomous system number it is originated from) does not correspond with the certificate created. For instance, AS123 created a certificate allowing itself to announce 1.1.0.0/22 but instead you receive 1.1.0.0/22 from AS456. Since there is no certificate, the route from AS456 is invalid and should not be accepted into the routing table (even if the AS path is shorter or the local preference is higher than on the route from AS123). This is known as BGP Origin Validation.

Participate In Your Local NOG

In this book, you’ll find tested use cases to make your network more secure. The authors use these in production networks and have verified that they work at the time of this writing. However, everything does not always stay the same. New developments lead to new features in our routers’ software. Existing software may have bugs that need to be worked around. In the fast-moving world of BGP networking, it is important to stay informed about changes. Our advice in this regard is to get in touch – and stay in touch – with your local Network Operators’ Group (NOG). Some NOGs have been around for years and years (like www. nanog.org or www.nlnog.net) and have regular conferences and other events. Other NOGs may be smaller and consist of only a mailing list or IRC channel. Whatever the NOG in your area can offer, it pays to participate.

Some use cases in this book have been taken from the NLNOG BGP filtering guide, which can be found on http://bgpfilterguide.nlnog.net. This website is regularly updated as new ways to secure the Internet are found. We recommend checking there every now and then and implementing any new recommendations found there.

Conclusion

Networks need a secure routing table in order to keep bad traffic away. A secure routing table does not contain invalid or bad routes. In order to achieve this as closely as possible, there are multiple ways of filtering route advertisements, such as implementing policies, or by using RPKI.

Filtering and rejecting routes is not scary and does not generally cause reachability issues: in cases of obvious BGP hijacks, rejecting the routes is undeniably good, and in case someone has made a typo in their route announcement, rejecting the route will actually help reachability instead of hindering it.

Now let’s get started securing your routing table!