Attacks against the routing system are increasing, and it's not uncommon in today's Internet world to experience prefix hijacking. The IETF has for a while, been woking on an Internet Resource Public Key Infrastructure, to help validate routing (BGP) announcements.
Details on RPKI and how this works is best followed up through your RIR. The RIPE-NCC in particular has excellent resources for you to peruse, and another excellent set of guidelines is available at https://rpki.readthedocs.io. INX runs separate workshops on IRR and RPKI usage, so look out for our announcements, and join the classes.
At INX-ZA, we operate a few RPKI validators that we use in production, and which, in true community spirit, we make available to the general public for use. These are spread across South Africa, and are freely available for use for prefix validation. We stongly recommend that each network implements their own set of validators, and provide these for use as backup and/or failover validators primarily for peers at the INXes, who are typically one network hop away from us. We place no restriction on reasonable use.
vc1-jnb.inx.net.za (Routinator 3000)
vc1-cpt.inx.net.za (Routinator 3000)
vc1-dur.inx.net.za (Routinator 3000)
All of the hosts are dual-stacked; please remember to use the v6 addresses, if your router supports IPv6.
The above are meant to be used by your routers, and don't have pretty front-ends, we also operate an easy to use RPKI validator that will help you manually debug your ROAs. This is available at https://rpki-validator.inx.net.za
Of course the point of RPKI validation is for your network equipment to do this automatically, so we suggest the following configuration:
router bgp 65001
bgp rpki server tcp <<host>> port 3323 refresh 900
assign a higher local-pref to prefixes that have a Valid ROA
leave prefixes with Not-Found ROAs untouched
drop prefixes with Invalid ROA
Dealing with Invalids
Operators may be tempted to choose an approach where they set the local-pref of Invalids to something really low (ie. least preferred). The simple problem you're still likely to see is that a more-specific (ie. longer match) route for this, will still win in the BGP route selection process, and therefore still leave you vulnerable to attack.
Should you need assistance with this, please feel free to send a mail to ops [at] inx.net.za