maximum ipv4 bgp prefix length of /24 ?

Tue Oct 10 20:36:26 UTC 2023

On Tue, Oct 10, 2023 at 12:58 PM Delong.com via NANOG <nanog at nanog.org>
wrote:

> Isn’t this supposed to be one of the few ACTUAL benefits of RPKI — You can
> specify the maximum prefix length allowed to be advertised within a shorter
> prefix and those (theoretically) block hijackers taking advantage of
> advertising more specifics to cut you off?
>
> While I recognize that RPKI is not ubiquitous, enough of the major
> backbones are dropping RPKI invalids that I think any sort of hijacking in
> violation of that wouldn’t be very effective today.
>
> YMMV of course, but that seems to me to be a far better solution (almost
> enough to make me rethink the questionable value of RPKI) than
> disaggregation.
>
> Owen
>

Owen,

RPKI only addresses accidental hijackings.
It does not help prevent intentional hijackings.

RPKI only asserts that a specific ASN must originate a prefix.  It does
nothing to validate the authenticity of the origination.

If I am AS XX, and want to hijack a prefix from AS YY that has RPKI ROAs
protecting it, and AS YY has allowed more specifics to be announced within
the prefix range covered by the ROA, I'm in like flynn, because I just need
to configure my router with AS YY as the origin AS, then insert the
expected ASN for the neighbor adjacency with my upstreams, and bob's your
uncle, the more specific prefix passes RPKI validation, and traffic comes
flying my way.

If AS YY doesn't allow longer prefixes within the scope of their ROA, then
it's a bit dicier, because it comes down to AS-PATH length, but there's
still a good chance you can suck in traffic from your adjacent neighbors.

So yes, hijackings in violation of RPKI aren't as effective, but RPKI
doesn't prevent intentional hijackings--it just protects against accidental
misconfigurations and unintentional hijackings.

Thus, deaggregation is still very much part of the defensive toolbox, even
with RPKI in place.

As a side note, it's also a really good reason why you shouldn't allow
longer prefixes to be announced under your ROAs, except under very well
understood conditions.   ^_^;

Thanks!

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20231010/f4dd13c9/attachment.html>