Filtering with ‘Never Via Route Server’ on PeeringDB

PeeringDB recently announced a new feature that allows networks to indicate whether or not they should be reached via route servers. This new function serves as an additional preventative measure to avoid catastrophic BGP route leaks.

The internet as we know is comprised of autonomous networks of all sizes that are interconnected at different points around the globe. All these autonomous networks allow traffic to travel between them to reach an intended destination. 

For example, if a person searches for a video on Youtube at home from their laptop, their residential internet service provider (ISP) then needs to search for a path to reach the content they requested across vast distances. This almost always requires the ISP to forward the traffic to partner networks.

All internet traffic is exchanged in two of the following ways: through IP Transit or through peering. The main difference? Through IP Transit, smaller networks pay larger ones to reach the entire internet. Under this arrangement, there is an established hierarchy with one entity benefitting more than the other.

Search on PeeringDB faster & more easily with this Chrome extension

Download the extension

Peering, on the other hand, is a mutual exchange of traffic between two or more networks, and tall parties involved benefit. Peering also takes place in two of the following ways: private peering and public peering.

With private peering, networks mutually accept each other’s traffic without additional costs or charges to each other. The exchange is established through a cross-connection made at a common point of presence (like data centers) rather than at a public internet exchange point (IXP).

Networks that choose to exchange traffic via public peering at an IXP establish peering relationships with each other. As the number of connected parties increases at an IXP, managing peering relations become increasingly difficult.

To manage these peering relations, each of these IXPs normally counts with route collectors and route servers. Route collectors, as the name suggests, gather routing information from the other members of an IXP. Router servers then broadcast these routes to participating IXP members according to their routing policy definitions. 

All of this activity is why the Border Gateway Protocol (BGP) exists. The BGP is a standardized exterior gateway protocol that automatically makes routing decisions based on paths, network policies, or rule-sets that are configured by each network.

By using BGP, networks can automatically identify the best paths (AS_PATH) to reach their destination. When new paths become available they become visible to the whole world. And this is why PeeringDB’s ‘Never route server” network configuration is important.

Let’s say there’s an accident that closes down a major highway, not wanting to be stuck for hours thousands of drivers then search for an alternate route. Their GPSs then suggest traveling through a nearby neighborhood street. All those drivers then proceed to drive through a neighborhood street that is not designed for heavy traffic and becomes so heavily congested that it becomes inaccessible and all traffic comes to a halt.

A similar situation can happen when networks exchange traffic. When an invalid routing path is broadcast to the rest of the world it is referred to as a BGP routing leak that leads to internet outages.

Now routing leaks are not always configuration errors, they can also be the result of malicious intent. When a network corrupts the routing paths of others to illegitimately take over them it is called hijacking. Both of these types of routing threats are unfortunately all too common. More than 14,000 incidents were recorded in 2017 according to a report by the Internet Society. Of the total incidents, 62% of them were considered BGP route leaks and hijacks.

One of the most catastrophic routing leaks occurred recently in 2018 when Verizon and a BGP route optimizer mistakenly communicated a bad path that then routed immense traffic through a  small ISPs network that was unable to deal with the load and basically led the internet to experience a heart attack.

How can networks prevent routing leaks? One way is to use “Filtering” to ensure the correctness of path announcements. These filters are configured by each network’s administrators. This means the internet depends on every network doing its part to configure the right filters and propagate the right paths. 

PeeringDB’s ‘never via route server’ network configuration serves that very purpose. When setting up BGP sessions, your script may connect to PeeringDB via API and filter networks marked with ‘never via route server’ and any route with one of those ASNs in the path will be automatically rejected. This new feature is particularly useful for Tier-1 networks.

This routing configuration solution was first pitched in late 2018 by Johannes Moos from DEC-IX. On an issues thread via Github, Moos described DEC-IXs interest in filtering out routes containing transit-free networks but that the challenge was to “come up with a list of transit-free networks that everyone could agree on and that was easy to maintain”. Queue PeeringDB. Because of its reputation as the “first stop when deciding where and whom to peer with”, PeeringDB has become an indispensable resource for internet exchange and was an obvious platform for this filter. 

“Never via route server” is a new feature at @PeeringDB which @DECIX proposed and discussed with the community. This feature is now honoured at all @DECIX Route Servers globally and 149 IPv4 & 51 IPv6 routes are filtered out at @DECIX Frankfurt. #peeringfamily #securerouting pic.twitter.com/91ZlHWc1Gu

— thking (@thking) February 13, 2020

PeerinDB’s announcement was echoed by DEC-IX’s Chief Technology Officer, Thomas King on Twitter. King celebrated the fact that within days of the feature’s rollout, nineteen of the major networks around the world had checked the ‘never via route server’ option on PeeringDB and that’s a fantastic start. It is now up to us, the global community to maintain accurate and up-to-date filters for our announcements and those of our customers. Make sure to update your network’s information on PeeringDB and verify whether the ‘never via route server’ configuration is right for your network.

Filtering with ‘never via route server’ on PeeringDB is just one of many precautions to prevent routing risks. To learn more about low-risk and low-cost methods that can help improve the security of routing infrastructure we recommend joining the MANRS (Mutually Agreed Norms for Routing Security) community – a global initiative that provides resources to reduce the most common routing threats. 

3 key benefits of peering at an IXP and how to start

Learn more about peering