Hi.
2. Perform originAS-only route validation for RTBH routes specifically, where the well-known BLACKHOLE [2] community must be present on the routes. Any widely-adopted RTBH filtering solution that ignores maxLength and relies only on originAS MUST require the BLACKHOLE community be attached. Everyone is leveraging that community by now, right? :)
I put together a setup where a router had a separate BMP session for BGP groups related to IP transit customers, that is, the BMP monitoring station received route monitoring messages only for prefixes which were from adj-RIB-in tables of IP transit customers. For example, Junos supports such BMP setup. On BMP monitoring station I had a Rotonda(by NLnet Labs) running which installed the prefixes to its RIB if they were allowed by Roto filter. The Roto filter allowed only /32 v4 and /128 v6 prefixes and either if they had RTBH community attached or they were withdrawals. On the same BMP station there was a Routinator 3000(by NLnet Labs) running and a small daemon which fetched the prefixes from Rotonda RIB using its API, validated that origin ASN of the prefix matches the covering VRP in Routinator using its API and finally wrote the validated prefixes atomically to a JSON file. This JSON file was read by RTRTR(by NLnet Labs) daemon every second and updates were pushed to router using the RTR protocol. Router had a separate RTR session for RTBH routes with RTRTR besides regular sessions with Routinator 3000. Rotonda, Routinator 3000, RTRTR and custom daemon were all running in the same host. Corresponding validation records for RTBH routes advertised by IP transit customer appeared in the router's validation database within few seconds. None of the import policies in router was changed, but the order of policies in import policies list was modified. The RTBH check was moved after the RPKI check. RPKI check policy in Junos can be seen below: root@vjr-17> show configuration policy-options policy-statement rpki-check term reject-rpki-invalid { from { protocol bgp; validation-database invalid; } then { validation-state invalid; reject; } } term mark-rpki-valid { from { protocol bgp; validation-database valid; } then { validation-state valid; next policy; } } term skip-rpki-unknown { from { protocol bgp; validation-database unknown; } then { validation-state unknown; next policy; } } root@vjr-17> I haven't tested it thoroughly, but in principle something like this should work too. Martin