BGP Hijacking and BGP Security

Another BGP hijacking event took place last week. This one involves Rostelecom AS12389, a Russian state-owned telecommunication company, hijacking routes to Google, AWS, Cloudflare and others. In fact, this event impacted over 8,000 prefixes of many different ASes.

That is newsworthy, no doubt, and many people have talked about it. I do not seek to add to that conversation. I want to fix problems, and help enable network operators to operate more secure networks.

BGP Hijacking is a long-standing problem and is a constant possibility in today’s BGP environment. These news stories will continue for some time to come, but there are things the community can do to limit the impact of these events.

It is time to talk about BGP.

Border Gateway Protocol (BGP) exists to share network routing information. This is the configuration data that allows networks to send IPv4 and IPv6 traffic towards the destination. BGP is the most fundamental protocol of the modern day Internet. It has stood the test of time (the first RFC is from June 1989), with several improvements along the way. But, as implemented, there are still many improvements network operators should consider.

Improving fundamental protocols on the Internet takes a long time. Standards bodies and researchers work on design, specification, and testing well before operators adopt newer options. Hardware and software vendors need time to incorporate proposed changes into their code base.  Organizations need time to upgrade their hardware or software to support these basic changes. All of these steps have definitive costs to them. To complicate global security concerns, sometimes the benefit is mostly a collective benefit. These tend to be difficult for some network operators to sell as a legitimate business need. And this pithy list is far from a full enumeration of complications!

With BGP, there are several improvements in these various stages of development. Recent events (such as this Rostelecom routing leaks) have sparked some more calls to arms to move things forward. 

We have compiled some resources for BGP protocol enhancements that may help you decide what is best for your network. Please review this list and review your network posture. Do what you can to help secure BGP for yourself, for your customers and peers, and for the world.

BOGONS

Bogons are network addresses that should not appear on the Internet. They are either designated for special use or are not yet allocated to a network operator. In either case, receiving these prefixes from your peers or pushing these prefixes to your peers is a bad idea. Team Cymru offers a free community service to allow network operators to filter these routes at their perimeter. Easy to set up, and we handle all changes to delegations and assignments for you.

More Information

http://www.team-cymru.com/bogon-reference.html

(Click the green Request Session button at the bottom to receive these routes via BGP.)

RPKI Route Origin Validation

Resource Public Key Infrastructure (RPKI) allows network owners to assert their ASN (Autonomous System Number) as the only valid origin for their prefixes, as well as the valid prefixes and valid masks.  Networks can configure devices to not accept advertisements that do not match the RPKI Route Origin Advertisements (ROAs).  This is generally supported and available for wider adoption. Networks should consider publishing ROAs and should consider rejecting invalid routes.

More Information

https://www.arin.net/resources/manage/rpki

https://nlnog.net/static/nlnogday2018/7_RPKI_NLNOG_2018_Niels_Raijer.pdf

EBGP “Default Deny” (RFC8212)

A prominent source of route leaks and routing mishaps is simple operator error, or misconfiguration. Those that have been in the industry long enough will have at least one epic story tied to operator error! RFC8212 helps to pave a way to protect against this mistake by changing the “Default Allow” to “Default Deny”. (Currently, the default configuration for most routers is to accept all routes learned through BGP sessions and advertise all routes known to all peers). Here, “Default Deny” means only accepting routes configured in the Import Policy and only advertise routes in the Export Policy.

More Information

https://tools.ietf.org/html/rfc8212

https://github.com/bgp/RFC8212

Peer locking

Peer locking allows AS owners and their peers to establish agreed upon filters to protect the Origin ASes of networks that do not have a lot of transit peers. Consider the following situation.

Example BGP Speakers

Peer locking in this example could work like this:

AS 64496 tells AS 65551 that only AS 65551 and AS 64497 are valid for their advertisements. Since AS 64496 is a direct peer of AS 65551, AS 65551 happily accepts this information and sets up rules to only allow AS 64496 in paths learned directly or learned as “64497 64496 i”.

Suppose that 64666 later leaks routes and presents “64666 64496 i” to AS 65551. AS 65551 would reject this route. This allows AS 64496 to protect from AS 64666 carrying traffic for their prefixes.

Consider AS 64666 deploying new BGP optimizations for traffic engineering purposes. Now suppose AS 64666 has a faulty configuration that results in a more specific route leaking to their peers. In this case, AS 65551 will reject the more specific routes for AS 64696’s prefixes. AS 65551 and all of the networks who see a shortest learned route takes the “* 65551 64696 i” path will be unaffected by this route leak.

Let’s suppose AS 64697 does not offer peer locking. Unfortunately, AS 64697 and all their peers that who see a shortest learned route of “* 64697 64696 i” will be impacted by this route leak.

In this example, AS 65551 offers a higher degree of protection and a better service to AS 64696. Each and every time an AS decides to offer peer locking, the global state of BGP improves.

Peer locking ‘Big Networks’

This same concept can be used to limit propagation of routing leaks by transit-free networks (previously known as Tier 1 networks). Because they are transit-free, no more than two transit-free ASes should ever occur in the same AS path.

The ‘Big Networks’ should never accept routes from their peers if the AS paths contain other ‘Big Networks’. The ‘Big Networks’ all peer with each other and with enough other ASes that they should never need to use another transit-free network as a transit provider.

More Information

https://www.senki.org/operators-security-toolkit/bgp-route-hijack/recommendation-deploy-peerlock/

http://instituut.net/~job/peerlock_manual.pdf

Conclusions

A friend of mine used to have an email footer line that said “I route, therefore you exist.”  The end game in routing is for traffic to make it to the intended destination. BGP and network operators do a tremendous job at making that happen. The Internet mostly works!

Some BGP configurations make traffic redirection via hijacking easier than needed. The techniques discussed here can help limit the impact of invalid BGP routing information.

As a community of network operators, we can improve routing security. Consider your network and where the techniques above may fit into your routing policies. As a community, we can ensure the Internet tomorrow is a safer and more secure place than the Internet today.