Re: How to validate blackhole routes? (Was: trouble letting go of IRR)

[Bryton Herdes via NANOG <nanog () lists nanog org>]

> So perhaps RPKI-valid-of-more-specific is safer.

The problem I see with performing originAS-only RPKI validation on
more-specific routes—something DE-CIX route servers do [1] using a BIRD
config knob [2]—is that some networks might use that originAS-only
validation in their (wide) configurations to make things "easier" for
themselves. This could become especially true if vendors adopt a
configuration allowing the loose validation of more-specifics' originAS
similar to the BIRD config. This would obviously go against RFC9319 and
make maxLength protections ineffective within the AS doing filtering.

To solve for RTBH, the immediate options I see are:
1. Job's proposal that relies on the covering route having already passed
through filters, RPKI validation, etc. and compares the recent historical
next hop (AS) lookups to assume customer authorization to announce
more-specific routes.
OR
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? :)

Again I feel the need to reiterate the "slippery slope" of #2 if it isn't
strictly paired with BLACKHOLE community usage, especially if vendors offer
a shortcut configuration for this in the future.
It's also noteworthy that #2 cannot safely account for the "TE" use-case,
as described earlier in this thread. I still question the validity of that
"feature" by which prefixes are internally floated in an AS and externally
rpki-invalid, as it could just be an issue of operator BGP prefix
mismanagement that made this feature attractive in the first place.

#1 could solve for the TE use-case as well, but my opinion of it is no ISP
should accept these more-specific invalids until they have implemented
proper safeguards that implement BGP hijacks. IRR will continue to not
offer sufficient filter generation for that use-case in addition to RTBH.

[1]:
https://docs.de-cix.net/article/o80or2w5dl-de-cix-chicago-globepeer-route-server-guide
[2]: https://bird.network.cz/pipermail/bird-users/2021-March/015314.html
[3]: https://datatracker.ietf.org/doc/html/rfc7999

--
Bryton Herdes
Principal Network Engineer
AS13335 - Cloudflare


On Mon, Mar 2, 2026 at 7:15 AM Saku Ytti via NANOG <nanog () lists nanog org>
wrote:

> On Mon, 2 Mar 2026 at 15:09, Job Snijders via NANOG
> <nanog () lists nanog org> wrote:
>
> > I would benefit from a few more words on what exactly you mean with the
> > above. Do you mean to say that if the customer AS is 65535, you'd only
> > permit blackholes if they are contained within the prefixes for which
> > AS65535 is an authorized origin, according to RPKI ROAs? Sure, that
> > seems a reasonable precaution.
>
> Yes. Sort of pretending ROA allowed to /32 or whatever the specific
> may be, IFF there is a blackhole community attached.
>
> Ignoring active path.
>
> --
>   ++ytti
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/TK6KESEBPS7HUPKSJTAWV235LI4FWZO7/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/VSS7L7QJXW2EDTYYCAWWIQYGLN3V6S3B/