On Wed, Mar 31, 2021 at 04:34:12AM +0200, Ondrej Zajicek wrote: > So my point/idea is that if this case is valid, then using RPKI-style > checking for BLACKHOLE is broken idea anyway,
Yes, the design pattern of using ROAs for blackholing appears problematic. Mangling ROAs and then using the resulting deteriorated information to 'approve blackholes' appears to defeat the purpose of RPKI ROAs. ROAs exist to help increase network reachability :) > and perhaops we should instead focus on implementing (IMHO) proper > checking for BLACKHOLE routes, similar to one for flowspec validation: > > BLACKHOLE route received from A is valid if i have (RPKI-valid) > regular route from A for network N covering the BLACKHOLE route > and (optionally) such route is best route for network N. +1 The above appears a worthwhile direction, more elegant than overriding a cryptographically signed attestation on the expected prefix length. 'ignore max length' appears to me as a dangerous button. I support Pier's suggestion to remove this config knob because of the risk of unintended consequences. In the below slide deck I've outlined some suggestions to make activation of blackhole requests dependent on 'normal routing', and in doing so - any and all work to improve 'normal routing security' will also improve 'blackholing routing'. http://iepg.org/2019-03-24-ietf104/blackholing_reconsidered_ietf104_snijders.pdf Kind regards, Job
