Early November, all active members and resellers were invited to give their opinion on the route servers filtering policy they would like France-IX to adopt.

Early December, we shared with you the vote results and the next steps. We have now reached a key milestone with the implementation of IRR and RPKI/ROA filtering capabilities on each router server during February.

Reminder about the route filtering on the Internet:

Reliable tier 1 operators have long been applying a filtering based on databases called IRR (Internet Routing Registry). These databases are managed by RIRs (Regional Internet Registries) and contain the resources allocated on the Internet, including IP addresses and Autonomous System Numbers (ASNs). Other entities complete or aggregate these databases in order to have a comprehensive vision of the Internet resources.

More recently, RPKI infrastructures have allowed IP networks to verify the origin of BGP announcements thanks to ROAs (Route Origin Authorisations). The functioning of ROAs is detailed on the RIPE page of resource management and certification. The RPKI infrastructure being more recent, the adoption of a filtering based on ROAs is not yet systematic among operators.

Filtering at IXPs level:

Although at the beginning RS were considered as simple route relays between the different networks connected to the exchange point, without intelligence, they have evolved gradually to bring filtering functions. This filtering service is mainly intended to facilitate the peering management for the members connected to the IXP, and increase the security between them.

Quite rapidly, good practices have emerged on RS to filter unwanted prefixes such as bogons (https://www.team-cymru.org/bogon-reference-http.html), or routes that include a private AS in their path.

On the other hand, some exchange points took the initiative to tag the routes with BGP communities so that their members can easily identify the ones that are not included in IRR databases or those with an “INVALID” ROA. This way each member could define their own filtering policy according the BGP communities. France-IX has been proposing this filtering mode since spring 2017.

RS have evolved over time and most members now wish to have this IRR and ROA filtering to be done by default by the IXP. Some IXPs are currently considering applying this strict filtering, while others have already implemented it. A strict filtering by default ensures enhanced security, as the adoption is high from the very start.

Obviously, members wishing to continue to receive tagged routes in order to apply the filtering themselves, will be able to request this.

Timeframe for the application of the strict filtering on France-IX’s RS:

In order to respond to the need expressed by the members through the vote issued last November, France-IX has prepared the various actions required to carry out the strict filtering implementation on RS:

• December 2017/ January 2018: a looking-glass was implemented, allowing members to analyse how RS will interpret their route announcements. Useful commands are listed below, while others are available on https://lg.franceix.net/ :
• Routes with “ROA invalid” status for an origin ASN (no ROA invalid route originated by AS57734 in this example) : https://lg.franceix.net/roa_invalid/RS1+RS2/ipv4?q=57734
• Routes with “IRR not found” status for an origin ASN (i.e transit networks of $ASN with IRR records possibly not up-to-date) : https://lg.franceix.net/irr_notfound_for/RS1+RS2/ipv4?q=57734
• Routes with “IRR not found” status which are announced by ASN (this ASN has a peering with the RS) : https://lg.franceix.net/irr_notfound_from/RS1+RS2/ipv4?q=57734
• All routes with “ROA Invalid” state : https://lg.franceix.net/all_roa_invalid/RS1+RS2/ipv4
• All routes with “IRR not found” state : https://lg.franceix.net/all_irr_notfound/RS1+RS2/ipv4
• December 2017/ January 2018: a testing environment was implemented to validate the application of the strict filtering and confirm there is no side-effect.
• 8 February 2018: maintenance for the implementation of the strict filtering on RS-MRS-1 (Marseille) and RS-PAR-1 (Paris). After this maintenance operation, members will be able to observe for a week the difference between routes received from RS1 (strict filtering) and RS2 (non-strict filtering with the tagging of communities).
• 15 February 2018: maintenance for the implementation of the strict filtering on RS-MRS-2 (Marseille) and RS-PAR-2 (Paris). After this maintenance operation, by default, members will no longer receive the routes identified as “IRR not found” or “ROA invalid”.

 How is a route identified as “IRR NOT FOUND” or “ROA INVALID” by the France-IX RS?

“IRR NOT FOUND”: for each member connected to France-IX, an algorithm searches for the AS-SET object associated with the member’s ASN. First, the AS-SET is researched in the “IRR Record” field on PeeringDB. If the field is empty, the algorithm will try to find an AS-SET in the “AUT-NUM” object through the “export” lines (RPSL syntax). It is therefore crucial that the “IRR Record” on PeeringDB is fully completed with the AS-SET or if this is not possible, the AUT-NUM. 

Once the AS-SET object (or AUT-NUM) is found, the algorithm searches and establishes a list of the ROUTE objects defined for the AUT-NUM present in this AS-SET (or AUT-NUM). The bgpq3 tool is used to do this recursive search, using the IRR database from NTT (rr.ntt.net) and the following sources as parameters:

RIPE, APNIC, AFRINIC, ARIN, LACNIC, NTTCOM, ALTDB, BBOI, BELL, GT, JPIRR, LEVEL3, RADB, RGNET, SAVVIS and TC

This list of IRR entries is stored in our information system and then replicated locally on the RS. When a route is announced, the RS will search if it is included in this “IRR FOUND” list for the AS that announces the prefix (first-AS). If so, the route is then tagged by the RS with the BGP community “51706:65011”. Otherwise, the BGP community “51706:65021” is added to the route and it will be rejected by default.

“ROA INVALID”: a local instance of the RIPE RPKI validator is installed in France-IX’s infrastructure, allowing to have a copy of ROA entries and thus generate a list stored in our information system and then replicated locally on the RS, in the same way as for IRR entries.

When a route is announced, the RS checks the route status for the Origin AS. If the ROA status is “VALID” or “UNKNOWN”, the route is tagged respectively with the communities “51706:65012” or “51706:65023” and is accepted. If the ROA status is “INVALID”, the community “51706:65022” is added and then rejected by default. It is therefore essential that ROA declarations with the RIR are achieved properly (https://www.ripe.net/manage-ips-and-asns/resource-management/certification/resource-certification-roa-management).