nanog mailing list archives

Re: How long AS-PATH policies have you used


From: Saku Ytti via NANOG <nanog () lists nanog org>
Date: Thu, 26 Feb 2026 11:53:09 +0200

Your other post is saying just ignore AS-SET.

Your solution is actually below AS-SET security. Which I would need to
market internally. I am trying to get rid of the prefix-list while
maintaining AS-SET compliance.

Let's say that my own AS43792 advertises google's prefix to us, with
correct ASN. Accidentally, no malice. Today we stop this, because
prefix-list. Can I explain to my managers and the Internet how we
allowed google from stubby customers to reach the entire Internet?
AS-SET is trash, but it drops this. And we drop it today, downgrading
may be hard to market. So there is plenty of coverage AS-SET does
give, despite being trash.

Only thing you are offering for this, is ASPA in future or peerlock today.

But peerlock is anticompetitive, why bigtech gets preferential
treatment and someone else who doesn't pass the bar, doesn't get
peerlock treatment from us? Why should we reward monopolies with
better products that we don't offer everyone? I think peerlock may be
literally illegal under some jurisdiction antitrust law, unless
everyone can contact us and demand to be in peer lock. And this
mechanism doesn't exist.

Yes we are doing it, and yes we wouldn't stop doing it. But we are in
addition offering prefix-list filtering today, to offer some cover to
those, who are not worthy of peerlock. And can I stop doing that?

So are you saying, I shouldn't do b+c, despite the fact that I am
retaining AS-SET compliance as I am today. I am not _removing_ any
posture, I am adding posture.





On Thu, 26 Feb 2026 at 10:40, Saku Ytti <saku () ytti fi> wrote:

On Thu, 26 Feb 2026 at 10:34, Job Snijders via NANOG
<nanog () lists nanog org> wrote:

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?

Either you generate
  a) prefix-list from AS-SET
  b) as-path filter from AS-SET
  c) fill RPKI /gaps/ with slurm from AS-SET

In each case, the quality of the check is as good as AS-SET, which is
bad. But in no case are you diluting the quality for prefixes which
have RPKI.
But in case of c) you are not just checking that the prefix comes from
the right port, you are also checking that prefix has the same origin
as route object.

So yes c) is much worse than not having a gap. But b+c) is much better
than a) because a) doesn't care who is announcing it. So you're
getting rid of a) scale,
while adding an ASN check, having overall better posture.


a) match port
b+c) match port + origin ASN





--
  ++ytti



-- 
  ++ytti
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/K3Q72BAUC3QVQGD5IBFPSDN4BBFIMGM2/


Current thread: