> On Oct 10, 2023, at 22:44, Willy Manga <[email protected]> wrote:
>
>
>
> > On 11/10/2023 03:52, Delong.com wrote:
>>
>>> On Oct 10, 2023, at 13:36, Matthew Petach <[email protected]> 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
