Re: maximum ipv4 bgp prefix length of /24 ?

["Delong.com via NANOG" <nanog () nanog org>]

> On Oct 10, 2023, at 22:44, Willy Manga <mangawilly () gmail com> wrote:
>
>
>
> > On 11/10/2023 03:52, Delong.com wrote:
> >
> > > On Oct 10, 2023, at 13:36, Matthew Petach <mpetach () netflight com> wrote:
> > > [...]
> > > Owen,
> > >
> > > RPKI only addresses accidental hijackings.
> > > It does not help prevent intentional hijackings.
> > OK, but at least they can help limit the extent of required desegregation in combat unless I misunderstand the whole 
> > MAXPREFIXLEN option.
>
> Actually, RFC 9319 do recommend to "avoid using the maxLength attribute in ROAs except in some specific cases". But I 
> recognise that this RFC is not yet implemented everywhere.

It’s a BCP, and may be worthy of reconsideration.

The justification in section 1.0 paragraph 3 of that basically points out exactly what I said people _SHOULD_ be doing 
_IF_ they use max prefix and have failed to do in “84% were vulnerable…”.

> > > RPKI only asserts that a specific ASN must originate a prefix.  It does nothing to validate the authenticity of the 
> > > origination.
> > Nope… It ALSO asserts (or can assert) an attribute of “Maximum allowed prefix length”.
> > E.g. if I have a ROA for AS65500 to originate 2001:db8::/32 with a “Maximum Length” attribute of /36, then any 
> > advertisement (even originated by 65500) that is longer than /36 should be considered invalid.
>
> Yes, but in that scenario any advertisements between /32 and /36 from that prefix originated by AS65500 are *valid* . 
> That's why "ROAs should be as precise as possible, meaning they should match prefixes as announced in BGP" [1]

You completely ignored my statement of the need for appropriate AS-0 ROAs to block those.

Owen