Since the beginning of March, RPKI-based origin validation is deployed at all DE-CIX route servers. But RPKI-based origin validation is not the only filtering mechanism at the DE-CIX route servers. Route server security has always been a very important topic at DE-CIX, and the DE-CIX route servers have always provided a high level of security. Among other things, DE-CIX is one of the ten founding participants of MANRS, the Mutually Agreed Norms for Routing Security initiative, supported by the Internet Society.
At DE-CIX, the route servers always filter based on AS-path as well as IP prefixes. The filtering mechanisms that are used to filter BGP announcements are described in detail in the DE-CIX route server guides.
The BGP announcements that a route server receives from a peer are checked against the AS-SET the peer has provided. The AS-SET can be changed by contacting the DE-CIX Customer Service team.
BGP Announcement Filtering – Extract from the route server guides
The DE-CIX filters are updated every 6 hours. Don't forget to register your IP prefixes in the IRR database well in advance (at least 24h before announcing the first time).
Bogon and Martian filtering
Please make sure not to announce routes that
- are > /24 (IPv4) and > /48 (IPv6) (RFC7454)
- have a different BGP next-hop than the IP of your own router
- are bogons/martians (private and reserved IP prefixes as defined by RFC1918, RFC2544, RFC3927, RFC 5735, RFC5737, RFC6598 and RFC6890)
- are a DE-CIX peering LAN (please also do not announce any of our peering LANs in the DFZ!)
- contain bogon ASNs in the BGP AS path (private and reserved ASN numbers as defined by RFC7607, RFC6793, RFC5398, RFC6996, RFC7300)
- differ in the leftmost ASN in the AS path from your own ASN
- have an AS path length > 32
- are < /8 (IPv4) and < /19 (IPv6) (RFC7454)
We will drop these kinds of routes.
Check the status of your routes
You can check the status of your announced routes to us in the DE-CIX Looking Glass – the reason why a route is filtered is also shown, as is a hint on how to fix the issue.
You can find more info on how to use the DE-CIX Looking Glass here.
IRR and RPKI validation
Any routes you announce will also be RPKI (RFC6811, RFC7115) validated and checked against Internet Routing Registry (IRR) data. The AS-SET you provide to us will be recursively resolved. Then filtering is executed as follows:
- Origin ASN needs to be in customer cone (make sure that your AS-SET is well maintained and that all your downstreams are included)
- Is the route a blackhole (RFC7999)?
- If no, the route undergoes strict RPKI validation filtering (both origin and maxLength):
- if the result is RPKI Valid, the route is accepted (a missing route object will have no implication in this case)
- if the result is RPKI Invalid, the route is rejected
- if the result is RPKI NotFound/Unknown, we check if the route is resolvable for its origin ASN (this will be the case if a proper route object exists) and it might get accepted or rejected depending on the result**
- If yes, the route undergoes loose RPKI validation filtering (origin only):
- if the result is RPKI Valid, the route is accepted
- if the result is RPKI Invalid, the route is rejected
- if the result is RPKI NotFound/Unknown, we check if the route is resolvable for its origin ASN (this will be the case if a proper route object exists) and it might get accepted or rejected depending on the result**
**Loose filtering on IRRDB route objects
We perform loose filtering on IRRDB route objects. For example: If you have a route object for 46.31.120.0/21 we will also accept e.g. 46.31.120.0/22 and other more specifics (up to /24 and up to /32 for blackholes). If this is not a desired behavior, we strongly encourage you to create a ROA and set the maxLength attribute accordingly. As RPKI validation is performed before the IRRDB route object check, it will render all undesired more specifics as RPKI Invalid, which will result in rejection of these. Please note that this method only works for non-blackholes as we perform loose RPKI validation on blackholes (i.e. ignore maxLength).
If you have any questions, please do not hesitate to contact us.