By preventing unauthorized routing changes, route hijacking, and other malicious activities, we protect your network connectivity and safeguard your data transmission.
Last Updated: 2021-06-10
One of the key concerns in routing security is preventing unauthorized routing changes. Without adequate protection, attackers can inject false or malicious routing information, diverting network traffic to unauthorized destinations or causing disruptions. To mitigate this risk, routing security protocols and mechanisms are implemented.
Here at Arelion, we take our responsibility to secure Internet routing very seriously. Through a mix of industry best practices, our systems, and well-crafted policies, we minimize the chances of common routing threats, including BGP hijacks and route leaks.
Spanning 75,000 km and serving customers in 125 countries, our backbone spans North America, Europe, and Asia. Fiber-up network control with cutting-edge optical and IP technology deliver the scalability you need, whenever you need it. And with customer experience at the heart of everything we do, we create a network experience so good, you won’t even know we’re here.
Explore our extensive network coverage with interactive maps, allowing you to make inquiries directly through the map. Download the static PoP Map for your region to keep it handy.
In our efforts to improve Internet routing security, we have joined MANRS, which is a global initiative, supported by the Internet Society, that provides essential fixes to reduce the most common routing threats.
As part of our membership with MANRS, Arelion commits to adhere to four concrete actions to reduce routing threats:
1. Filtering
2. Anti-Spoofing
3. Coordination
4. Global Validation
Have a look at the excellent MANRS observatory tool!
RPKI is a method to help prevent BGP hijacking and route leaks. It uses cryptographic signatures to validate that an ASN is allowed to announce a particular Prefix. Arelion’s ASN, AS1299, has deployed RPKI route validation and Filtering. We reject RPKI unvalids on all BGP Sessions; for both peers and customers.
PLEASE NOTE: It is not our intention to do anything other than filter out invalids – we will not be rejecting unknowns.
| RPKI State | Description | Recommended Action |
|---|---|---|
|
Valid |
Correct IP/masklength from the correct origin AS according to the ROA. |
All good. No need to do anything. |
|
Unknown |
No ROA registered. |
We recommend customers to register ROAs to protect their address space but it's not required. |
|
Invalid |
Incorrect masklength and/or origin AS according to the registered ROA. |
The address space owner should correct the ROA. |
We’ve been working hard on testing our validator infrastructure to ensure it is stable and scalable for a network of our size. In total, we have four validators deployed, two in North America and two in Europe, running two different versions of software. Each edge router has RTR sessions with each of the validators, giving us an extremely resilient deployment.
Have a look at Arelion’s BGP Looking Glass to see the status of learned prefixes.
RPKI Documentation Library - a great starting point on what RPKI is all about!
Look up validated ROAs
Analysis tool for more details on covering prefixes.
All eBGP Sessions have their filters automatically updated by our own “BGP Filter Server” Tool. This process runs twice daily; at 0700 and 2100 CET. For urgent updates needed between these times, customers can contact our Customer Service Center. A policy (AS or AS-set) registered in an IRR database is needed to build filters. We provision prefix filters by default and encourage customers to create and keep their IRR records updated.
The filter server mirrors in total 23 IRR databases. In case an AS-set exists in multiple database the default IRR query order is RADB, AFRINIC, RIPE, RIPE-NONAUTH, BELL, APNIC, NTTCOM, ALTDB, PANIX, NESTEGG, LEVEL3, LACNIC, REACH, AOLTW, OPENFACE, ARIN, ARIN-NONAUTH, JPIRR, HOST, RGNET, BBOI, TC and CANARIE. Route objects from all IRR sources will be candidates for prefix filters.
The Regional Internet Registries, AFRINIC, APNIC, ARIN, LACNIC, and RIPE, manage IP address allocations. All of these have an IRR where an operator that has received resources (AS numbers and IP addresses) from that RIR can register RPSL data (aut-num, as-set, and route-object). We recommend customers to maintain relevant RPSL information for their allocations in respective RIR.
We convert the Origin AS attribute from ARIN WHOIS network records and include them in our prefix filters.
All customers should have the ability to create relevant RPSL objects using a RIR. RADB is a commonly used IRR alternative, but ALTDB can also be used. All RIRs also have the option to create RPKI ROAs. We include ROA information (very similar to route-objects) in our prefix filters. In that way, we cover and can build prefix-filters for all IP addresses allocated across every region.
We encourage customers to follow the standards defined in MANRS regarding routing security, including filtering and maintaining database and contact information. More information can be found at https://www.manrs.org/
