Re: How long AS-PATH policies have you used

Dear Saku,

On Thu, Feb 26, 2026 at 09:10:02AM +0200, Saku Ytti via NANOG wrote:
> But this is highly encouraging, it does seem to suggest to me, that we
> have path out of prefix-list filtering and greatly reducing
> configuration sizes and commit times.

Yes, you do. But the below plan probably is not it. Some comments &
questions below.

> a) Use SLURM to bridge gaps in your customer cone (this is 20-25%
>    today and decreasing) using route origins

What is the purpose of this? What do you envision you could put in SLURM
to trick your routers that wouldn't dillute the purpose of the RPKI?

> b) Drop all non-valid RPKI (basically this is now your prefix-list check)

I strongly advise against this course of action. What network operators
currently do (both small and large) is to reject ROV INVALID. That's it.
The fail-safe is to fail open. The philosophy is that with
cryptographically-signed "high quality" information in hand, "radical"
decisions (such as rejection) can be justified to be performed
automatically. Lacking such information (e.g. your RTR server exploded)
the safest course of action is to fail open. Consequently operators
really should not reject BGP routes solely because they are "not-found".

It seems very fragile to me to depend on the well-being of RTR sessions
or the availability of the RPKI cache. In the past I myself found a
number of bugs to remotely crash RTR sessions and can imagine such
software defects to be re-appear in the future.

> c) Us AS filter to drop non-permitted origin

Sure.

> d) Much much faster AS-SET recursion

Sure.

> e) Avoiding having prefix-lists duplication (RPKI + IPv4 + IPv6, both
>    AFIs can use same AS check)

Sure.

> As far as I can see, this is actually more secure than RPKI-ROV +
> prefix-list, while being massively shorter in configuration size and
> commit time.

These are laudable goals and I will start a separate thread to elaborate
a bit more on what I implemented at Fastly.

> Of course AS-SET data is trash and is insecure, but that's a fight for
> another day. And the problem remains the same regardless of whether
> the prefix-list or ASN is generated.

Agreed.

Kind regards,

Job
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/B5SIP4RGORK5THYIAO4EOWLNGEWRQ5KE/