-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Friday, February 27th, 2026 at 10:29, Job Snijders via NANOG <nanog@lists.nanog.org> wrote: Hi Job!
I'm indeed not sure there is a meeting of the minds on what problem it is we are trying to solve.
OK, let's try to get on the same page, otherwise we're not going to have a useful conversation [1]. I think you are saying; if we drop all IRR derived data right now, that would be a net gain, and I think the reason you are postulating is that IRR derived data is insecure (specifically, prefix filter and AS path filters derived from AS-SETs can't be relied upon because anyone can add anything to an AS-SET at any time, and then it would be included in the prefix/ASP filters). Is my understanding of your argument correct? What I am saying is that it would be a net loss because, despite the flaws in IRR derived data, we're left with gaps in the currently tooling if we remove IRR derived data from our tool chain, and those gaps induced by removing IRR based filter are bigger than the gaps induced by the presence of IRR based filtering. If I have understood your argument correctly, then we have both put forward valid arguments and (IMO) we need to do two things now: 1. Expand on them / be specific (how exactly are we better/worse off with IRR data). 2. Provide some hard data which backs up our claims. For my argument, here is point 1... The are two main types of BGP routing issue I want to try and stop (there are others, but they are super rare IMO); accidental route leaks, and planned, intentional hijacks. ROAs, ASPAs, and IRR data, RFC9234, peerlock, BOGON filters, max prefix limits, etc; none of them protect against planned, intentional hijacks because anyone can fake data that would pass through BGP filters. In my experience, intentional hijacks are the exception, not the rule (by a significant margin!). So whilst I do want to protect against these, I have no reliable tooling for this at present, _and_ every decision we make "for" something is a trade-off "against" something else. I don't want to optimise for the corner case, I want to optimise for the common case; thus filtering accidental leaks is a higher priority for me. I will make trade-offs that favour blocking accidental leaks over intentional hijacks if there is no way to block them equally. I think it's important to clarify that. The idea that anyone can add anything to their AS-SET and then I will 100% accept what they send me is simply not accurate. Firstly, a customer of my peer tries to hijack my direct customer's prefix, but the AS path will be longer, so I won't prefer it. Secondly, someone could fake the AS path to ensure I receive a prefix with a shorter, or at least, equal length AS path, but it's pretty standard that networks prioritise received prefixes in roughly this order: customers > peers > IXPs > transit. So even with a faked origin and/or AS path, I still won't prefer the route. Thirdly, if such a direct peer/customer actually tried to implement such an attack (actively faking the BGP data) I would not be looking to increase my BGP filtering with them, this is the wrong approach, this is unacceptable, I would act to disconnect them from the network. You really need the "exact" circumstances for this idea to succeed, so for these reasons I don't think this risk as quite as high as people make out (and ROAs or ASPA et al. don't help here). Additionally to this, as long as ROAs don't exist for prefixes, but for which there is currently a route/6 object, I am gaining something from using IRR derived data when compared to not having it. As Saku said in his email, and I said in mine; AS-SETs are in prolific use and most of them seem to be working well. Removing them because their insecurity has been abused by a minority of bad actors doesn't seem like the correct approach to me (it feels to me like an over reaction). So I think the real question here is (correct me if I'm wrong): is AS-SET based filtering improving or weakening edge filtering when compare to not having it? This question ^ is basically point 2 that I wrote above "Provide some hard data which backs up our claims". So how about this: You provide points 1 and 2 for your case/argument, and I will go away and during next week, gather the data for point 2 of my argument, and we can meet back here? Cheers, James. [1] I realise I'm not answering a bunch of your questions, but aligning our discussion seems more important to me, in order for this discussion to progress. So just say if you want something from my previous email answered. -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsG5BAEBCgBtBYJpor83CRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3JnXjKwRvQyqgXkZTmjhRiEQenDuWk5CFfUmFIW zY1N5moWIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAY44QAJRkniBo2UzdbOML sWyKvZ/sZlnAPjice+RECueKsixo1uUOegwBjH+SP7GpeC1b6TY3sPs2IfVP TK3cPhEPN2j9pJxHYV+0ok0akiuNb8LqqHds9ipd6KBR54J8W91H+6AD68i/ 0fGPiOCo8Td/rzEAPvCD4GtSIX0PrUmZd75X5Oqa2nlZ7DCbg0e3zQeCRzQb lGFLjowQcljQfZsBq0NTTyDt4LlFh1aSz9uj7aAldKWov9jV++DY2ZKaFHEy jCXs5qXSPJg7fWzpJXpcr4JwUHVwf5TQ0uzMDClQmP658gGxs3elWOSLI61T 5Dtd/Hrk/5aRPy/4Hg3wLj7Hg5oEl69kPrUdOE86jCQ3WAFfs6ZxRflN/R+Z d+aT2WaKj4bZvH7mKgIIvTe+CCfx7NMneW5gNVuoJGdzLsDdlgkXHNChDxKJ Zo/yupQARxwYcM/2nUQDxotsOi4sET/UxJAAIkg4/NXOPrxZNvi6LZr0Ji6e 6MALNuhyZ3yf3G1momA2vLYLNHRiH+3KpMSU78hZep6sybQSIqjWFjrZR581 HMERg8kKG9aN2VpxxsYV3UaHXADqC7CVKghN9zazHXFh6l/bkiEbZTJjrhJh 9UHwzf02bUuAdauv4xiBkjUfpA663+C6JLeObIgF6OPdADjO1tQ/i3ncYDp7 1sz300XH =hZP4 -----END PGP SIGNATURE-----