AS-GTT expands to some +90k ASN. Over 65 AS-SET that we use expand to +10k ASN. However 75% expand to 100 or less, which I'm pretty comfortable is not going to be market leading exercise. Luckily in Junos, even AS-GTT actually works, since they've implemented regexless way to do AS_PATH for some cases - https://p.ip.fi/hHia For SROS, IOSXR 90k would be quite a ridiculous attempt, and it's probably cheaper just to expand to a million lines of prefix-list, since prefix-list scale is more tested than AS_PATH scale. In SROS as-path-group can contain only 128 lines, so if you match a single ASN per line, you'd need 700 terms just to check the origin, unless you use regexp OR in the lines to put multiple origins per line. On Tue, 24 Feb 2026 at 20:07, Tom Beecher <beecher@beecher.cc> wrote:

I've always gotten plenty of mileage out of as-path regexes on Junos. Usually don't ever need to be more than 4 long.

On Mon, Feb 23, 2026 at 11:52 AM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:

...

We've had problems in various NOS in generating large prefix-lists. In absolute configuration size, as well as prefix-set sizes.

I'd like to hear about operational experiences, how long AS-PATH policies people have successfully run and in which NOS.

I am not interested in exact AS_PATH contents, I am only interested that it contains a named set of AS numbers, in any order and any repetition. In Junos speak ^[1 42 500 1212]*$

How many ASN can I iterate, before I become market leading and have to work with vendors to fix bugs?

The interest is because of RPKI we could get rid of prefix-lists, but we might still want to verify AS_PATH. Consider AS-YTTI having AS43792.

a) They advertise google with invalid origin b) They advertise google with valid origin

Maybe these come from some BGP optimization tool they run. A) is dropped by RPKI, B) is passed. But B) can be dropped by prefix-list filter or AS-PATH filter which doesn't allow Google ASN to exist in the AS_PATH.

So I don't really need to check the prefix again, after it passed RPKI. AS_PATH check is equally strong.

-- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/O5XX6BHO...

-- ++ytti

Thank you, very useful. I assume you've previously used. non-EOS platform, were you running a similar scale there? And much larger than I expected from a regex based solution, so highly encouraging that this could work even for pathological AS-SETs. Is EOS using ASN as atom or character as atom? Your example has some ambiguity to me. permit (1|2|3|4|5|6|7|8)$ any This would work with both atoms. But permit (11|22|33|44|55|66|77|88)$ any has a very different meaning depending if character or ASN is an atom. AFAIK only Junos has ASN as an atom, which is a brilliant idea for regexp. 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. a) Use SLURM to bridge gaps in your customer cone (this is 20-25% today and decreasing) using route origins b) Drop all non-valid RPKI (basically this is now your prefix-list check) c) Us AS filter to drop non-permitted origin d) Much much faster AS-SET recursion e) Avoiding having prefix-lists duplication (RPKI + IPv4 + IPv6, both AFIs can use same AS check) As far as I can see, this is actually more secure than RPKI+prefix-list, while being massively shorter in configuration size and commit time. 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. On Wed, 25 Feb 2026 at 21:10, James Bensley <lists+nanog@bensley.me> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

On Monday, February 23rd, 2026 at 17:52, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:

...

...

I'd like to hear about operational experiences, how long AS-PATH policies people have successfully run and in which NOS.

...

...

How many ASN can I iterate, before I become market leading and have to work with vendors to fix bugs?

The largest AS path filter I can find on our network, is for one of our customers. The filter is 9002 permit entries long, each entry matches 8 ASNs, so 72016 ASNs in total.

To clarify, one "entry" is matching 8 possible origin ASNs:

permit (1|2|3|4|5|6|7|8)$ any

^ 9k of those.

This is on EOS, it works fine.

...

...

So I don't really need to check the prefix again, after it passed RPKI. AS_PATH check is equally strong.

This is exactly why we have AS path filters too. We're looking into dropping prefix filters but keeping AS path filters until such time as ASPA (or some other method) covers that part of the path filtering space, and we're also working on RFC9234 adoption right now. Prefix filters are yucky.

Cheers, James. -----BEGIN PGP SIGNATURE----- Version: ProtonMail

wsG5BAEBCgBtBYJpn0j2CRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3JnN12N5Tp4bXIUul/g6DT/CsmJOwkmWpuXCelO 6l0jC8cWIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAn0gP/R5eP0EjZMxvlsRn WwQTlc1YSk4kxWGmREIfSp6HBp8q0h+onH/7or2lKeihEM09RvmmapOpRPv1 TH+zZAHKEFhYjwFhYukUbmS0h4qe155WFz90pHoKnv/9n8BjTOlCTl9KzZ2H Psnmo5f3vluqv5DbfUCEh9/26SZdDcI4+i8YiFuaXBvI5lv26o2fTtxeNDel ysL5wp2DGFNXerhfwPWsHsFftoHn6yJeY9MPD/qhcwBW8P8pVh3dKQtdzCYP ZjwfssHmzThzM98LaJZxAqksaIhe/Hv5cT8fefJ4tnvrwa0I+K5mhDZ64tFT xiyiO8c1MhbYwARcqLdFJVBCNgkCGGz3dUVApLur7gaudJ+NfWPClNmKPD36 ZQrPVJ11d1zeKDL3VYq5yr8OQkEe+WtDGAhpcme1t1knYo37K6MAJVRxx7Yz By9z2qoy+33EMjb1yyGFFm8665vG6WswDgTAXcxs63DS1oL3vzMnZTSAsfpT xK5K7+1wkJRvOBjPDwvZ4wNoWURBDiLTxDanLLOJm+JXrHW98+wbTttSj82h gOrMTq2CyPb5dMM36TcvFeGAO8lZy+ll/BhsnJKGRkEoxL3S6sM+R/p6/egC LDNFtOsAlgiaJoE6JJjwHh0vGmHZMCxOS5mM+BAJUEhFN5/05zRW1LEQpw4y wjW/CN6w =3CTS -----END PGP SIGNATURE-----

-- ++ytti

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

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

On Thu, Feb 26, 2026 at 11:53:09AM +0200, Saku Ytti wrote:

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

Both efforts represent multiple years of work, you are welcome :)

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.

I think you may be holding some of this upside down: by locking a select few ASNs in such that they can only appear behind specific BGP sessions, your autonomous system helps protect the global Internet routing system. Save the cheerleader, save the world. ;-) For example, by locking in a large peer you not only help your own customers, but also their customers, and as a result also everyone's customers' customers. Global IP networks are a shared substrate. Another angle: by locking in a large content provider, when leaks are occuring elsewhere, it'll will help improve the chances of congestion-free access to not just that content but also other content for everyone using the network! Because peerlocking is a sharp tool, I'd strongly recommend to-be-locked-in networks to interconnect in multiple separate geographies in order to prevent network partitions following failure of individual links or routers. Obviously it is exceedingly hard to operationalize without direct relationship or direct interconnection, so that's why not every AS is a suitable candidate for being locked in; quite some ASes prefer flexibility over security. In this sense ASPA is far more attractive than peerlock because ASPA offers AS holders timely distribution of new routing intentions in standardized & automated fashion. ASPA certainly is a more accessible facility than peerlock. I myself consider attempts to reduce the blast radius and impact of routing incidents to be part of responsible corporate citizenship and most likely easily defendable. Kind regards, Job

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thursday, February 26th, 2026 at 08:10, Saku Ytti <saku@ytti.fi> wrote:

Thank you, very useful. I assume you've previously used. non-EOS platform, were you running a similar scale there?

No - we built a greenfield network a few years back so EOS only here and no prior NOSes to compare to.

Is EOS using ASN as atom or character as atom? Your example has some ambiguity to me.

permit (1|2|3|4|5|6|7|8)$ any

This would work with both atoms. But

permit (11|22|33|44|55|66|77|88)$ any

has a very different meaning depending if character or ASN is an atom.

Sorry, I could have explained that better. Firstly ignore the "any" on that end, that is matching the BGP origin type (IGP/EGP/unknown). To explain the line: (1|2|3|4|5|6|7|8)$ As I'm sure you know, $ matches "ends with". Each number before that between a vertical pipe is an "OR" and matches an entire ASN. So we're matching an AS path that end's with AS1 or ends with AS2 or ends with AS3, etc. This doesn't also match; ends with AS11 or ends with AS111 etc. There is (likely!) some optimisation we could do here, but like many things, it's working, I have a bunch of stuff that is broken, so no time to look into improving the efficiency of something that's working (i.e., I'm sure where we have continuous ranges of ASNs we could use regex ranges, but no time right now). You mentioned in a previous email about problems committing such large configs. For us, prefix filters and AS path filters are files on the router's disk. So in the device's config, it's just one line of config which references the file on the disk, the prefix filters and AS path filters aren't part of the running config. This massively reduces the config size.

90% of our "running config" then comes from the BGP policy ("RCF" in EOS terminology). RCF can also be files on disk. For us RCF is not in files on disk today, still in "running config". This is something that needs fixing; we have 175k lines of RCF on some edge routers. We've worked with Arista to get big functional changes into EOS (RCF now supports functions, and takes arguments like AS numbers, communities, etc., to avoid repeating code). This wasn't present when we started, hence the giant policies. We'll work on replacing this with functions, and then after that, see if we still need to separate RCF from running config out to files on disk. But so far, committing such large configs works fine and the plan is to address this before it becomes "not fine".

Cheers, James. -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsG5BAEBCgBtBYJpoUR+CRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3JnyWO1GROF+CNVyaX6XUhdfMPEodJA7oyBPfpP efZcFf4WIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAACg8QAJqjTegkRutKON4p vu83goG0tLUqtPyM7LwhNN3AzepnrKHTkZ6yduKEMz7FQIkCNDdq1dTIIo/f q/kQmH2PDa6C3uzF+yiJlv/mFTIWAq09JG3FOJJGAJtpXmyk2GrcbDoKl6xo tT2LBfCJ4anzthT/tyfqETfFdJ7Y1rXYTaVt8ET0xq/Xhc2I/wlTTS7A5tAs A+T2OicD9XW1HPjvb2FzyERORiHQc6n90+rX3OwvDC80fPo0eucknhPlIURK 41xntgbJpe0slpAyvdq5ezQISpCFVu8VtwL0MdZ3s77H3ElSU4Mr5Sr91OQu hP26uZRJovTNPl64EDOpdg8SqoFYB4eNO2y+qMkd9hu6Kvr8o0+p8iPT2F73 kfQlG48DmlFaEOK3EUqmb6no45D+XW0xdwJYPq4xP/13bPFlZSen+JTgUVIm czCVuL36W8y4JpMT2hFhQUmX0pKCmCogJvGFzKqBUX7dLMRzRW75h9/hyQ+a +wkn57WnkVd54HTmC2cnhUqE/zobcrMqxMSRNPO1J7oewUga1ginNZFbrY6d bDE0RYY0NfyiW99Rv11TmGm+cM2T4lWkbBuwfiPuAIsm8ZcIiMcsgNUh+ULQ yY03yudLcGp7G8XhIQMFa+CuWLnp9c5Z8uD2RNMDsG1uuPsInyuidjYx+2PF JpKOnC26 =mjUI -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Job, I agree with your end goal, but I think your approach is flawed. I am not trying to be an apologist for IRR derived data, but fully deprecating AS-SETs actually weakens our current security posture, and our current functionality. To be clear, I believe that ROAs and ASPAs are a step forwards, and I am personally, actively, working on RFC9234 and ASPA adoption. But fully removing IRR derived data is a bad idea (your assumption that most AS-SETs are garbage is not true in my experience, it's the minority that are garbage IMO). Firstly, here are three real world use cases we have which rely on IRR derived data; 1. RTBH; many networks have a ROA for their IPv4 /22 for example. They don't want people to hijack a more specific so they don't create ROAs for 4x /24s, and they don't create ROAs for /22 upto /24. They just create a ROA for the /22. Also they want to be good and only announce a /22, and not be part of the disaggregation problem. At some point my customer is under attack and announces host routes to me, or even say a /24, with the RTBH community. These are ROA invalid. Also, AS path filters derived from IRR data wouldn't allow this because there is no route object for the /32 or /128. To accept these routes I have to skip RPKI validation, and check they are a prefixes this customer is allowed to announce to me using IRR derived prefix lists (i.e., if object exists for /24, allow /24-32) and check the RTBH community is attached. If the route is RPKI invalid and in IRR prefix list and RTBH community is attached, I can accept the prefix and drop the traffic for my customer who is under attack. Without prefix lists everyone needs to extend their ROAs to be "up to 32" and "up to 128", or create ROAs for all their /24s and /48s and lose the ability to black hole host prefixes. 2. TE; same as above, my customer has an IPv4 /22 with a ROA for the /22 exactly. They connect to me in multiple locations and they want to steer traffic between these interconnects with me. They announce the /22 to me, which I announce to the rest of the world. In location A they also announce to me the first /24 from within this /22, and in location B they announce to me the second /24 from within this /22. These are ROA invalid, but I accept the prefixes as long as they match the customers IRR derived prefix filters, and they have the NO-EXPORT community attached. The customer has a /22, that is announced to the world, these /24s are for steering traffic within my network only, between the interconnects with their transit provider and their own network, so we don't announce them out further, but we let them TE traffic within our network. Like above, not possible without prefix lists. 3. Unused space; as a transit provider, of course people try from time to time to announce prefixes to us for which there is no ROA and there is no route object. They are usually spammers, trying to squat on some unused IP space. If I remove prefix filters and use your approach of accepting unless given a sign to reject, these become RPKI unknown and we would accept them. With prefix filters, these prefixes aren't in the IRR data, so they're rejected. Above are example of functionality that is lost if we wholesale remove IRR derived data (AS-SETs). Also, I think we can safely assume other networks have other uses cases which I haven't mentioned. Now let's also consider the security side of things; * We are years away from rejecting ROA unknowns, because this requires like >95% of prefixes to have a ROA. * We are years away from rejecting ASPA invalids (let alone unknowns!), because it's not even supported by all major vendors, requires truck roll to upgrade, and operators need to create ASPA records. * We are years away from wide spread RFC9234 adoption; again, not all major vendors support it yet, requires truck roll to deploy it. In the mean time, ample tooling exists for IRR derived filters and all major NOSes already support this. Networks could actually make use of IRR derived AS path filters as a stop gap until the above points reach a wider level of adoption and maturity. As Saku mentioned in the other thread here on NANOG, most AS-SETs are actually in good working order, and it is the minority that are total garbage. Until the above "replacement" technologies get to where we need them to be; having some prefix filters / AS filters, would actually improve security in the mean time, when compared to not having them, because if you don't have them, all you have is, what... BOGON filters and max prefix count? We get alerts from bgp.tools on a near daily basis of prefix leaks affecting our network and/or our customers, because people don't have *any* filtering of any sort, but IRR derived filtering could be deployed _now_. If you vendor doesn't support RFC9234 or ASPA, yeah you can start that conversation with them, but it's years away. We don't need to take an all or nothing approach, we can use IRR derived data now as a stop gap until these other technologies get to a point we can remove IRR data, but I don't believe we are at the point that we can fully remove AS-SETs / IRR derived data yet. Cheers, James. -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsG5BAEBCgBtBYJpoVq0CRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3JnJY1Z2o7ZGQmkFhu+NDLn1llZy0rfNagRxTp3 HfS/pI0WIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAh5cP/RWDVdKjHFp3I0mm hwfiwCc7V7fdmM+WbA8YAx0gLoArx2IlX+SrUlhgAq+KcLhVYj2PazEurJtG x4IgtsigwQBrj9gfihcHD8jQ3Xo9+tFuXXfcAFzBefKd1/yEvPMmpQ8fENlv 1J5y4x7edyEhim2KYNMypfZPDbe9WBH3T1HksPb7U1Iij7AaARke24mL68xR IJ5q2ICHpEffKZFPR8FJeJSRYmHhhwfTfrGzFj2pbvU3RSFJhtcc1NCFiSCS 8ecWEzl9ypqhZvcO1Tpo9TeBh6kvAR0wZr2Xn88jvMgB47IDz+kL+uqMsgnq hbRulbWReiMohXsurPCFzHyrcso6hqeXfXFxmbmXC2m1rpGYW4Oh9zbcbkea OgaYWx5qF0Td++8PCpvy4tVsRUIYHq4jW9hBpIzt1rqluH4Dkyy/WbDwV3Ip n3nfasSRuN+/0c1LThvLgqnWz2JzuJp5Ih4Nmss3kyxE+pikbivuW5t/C6Ta BoiQuxlcRCI6WQLAfCQvDm3Mno4Kxsdu7MQdw1IWR8AwJmF2tolasSvv1vBr HObfvb/+TgXPRk/mqAX0nqTnSBu6quWPrRN4lG+dhP/1YD7Fborr1a/DFBtN Ibd4ZsV9AHjmWNgd/Jq+720oXn6RcPuS1Atdf4EA6i1mLmUbD/WCoI58a12W i5xBBAmr =+4n1 -----END PGP SIGNATURE-----

Hello James, On Fri, Feb 27, 2026 at 08:50:13AM +0000, James Bensley wrote:

I agree with your end goal, but I think your approach is flawed.

I'm indeed not sure there is a meeting of the minds on what problem it is we are trying to solve.

I am not trying to be an apologist for IRR derived data, but fully deprecating AS-SETs actually weakens our current security posture and our current functionality.

What exactly is 'secure' about an AS-SET? How can those two words be used in the same sentence? As I understand it AS-SETs are plain-text blobs of unknown provenance which contain entirely arbitrary data for unknown purposes that can change at a moments notice.

To be clear, I believe that ROAs and ASPAs are a step forwards, and I am personally, actively, working on RFC9234 and ASPA adoption. But fully removing IRR derived data is a bad idea (your assumption that most AS-SETs are garbage is not true in my experience, it's the minority that are garbage IMO).

How do we measure these things?

Firstly, here are three real world use cases we have which rely on IRR derived data;

But do you really? Please read on ... (and thank you for elaborting on your use cases!)

1. RTBH; many networks have a ROA for their IPv4 /22 for example. They don't want people to hijack a more specific so they don't create ROAs for 4x /24s, and they don't create ROAs for /22 upto /24. They just create a ROA for the /22. Also they want to be good and only announce a /22, and not be part of the disaggregation problem. At some point my customer is under attack and announces host routes to me, or even say a /24, with the RTBH community. These are ROA invalid. Also, AS path filters derived from IRR data wouldn't allow this because there is no route object for the /32 or /128. To accept these routes I have to skip RPKI validation, and check they are a prefixes this customer is allowed to announce to me using IRR derived prefix lists (i.e., if object exists for /24, allow /24-32) and check the RTBH community is attached. If the route is RPKI invalid and in IRR prefix list and RTBH community is attached, I can accept the prefix and drop the traffic for my customer who is under attack. Without prefix lists everyone needs to extend their ROAs to be "up to 32" and "up to 128", or create ROAs for all their /24s and /48s and lose the ability to black hole host prefixes.

For RTBH the principle of "if I was gonna send you the packet _anyway_, then you may request the packet to be discarded" should be applied. Then there is no need to create insane filters from unreliable data sources: every step that's taken to improve 'regular' routing will positively impact the guardrails around blackholing functionality. I jotted down some thoughts here but then COVID got in the way: https://iepg.org/2019-03-24-ietf104/blackholing_reconsidered_ietf104_snijder... TL;DR - In order to offer safe blackholing functionality, the provider needs to ensure the blackhole comes from the same place the next less-specific active path is pointing to. Same idea as flowspec.

2. TE; same as above, my customer has an IPv4 /22 with a ROA for the /22 exactly. They connect to me in multiple locations and they want to steer traffic between these interconnects with me. They announce the /22 to me, which I announce to the rest of the world. In location A they also announce to me the first /24 from within this /22, and in location B they announce to me the second /24 from within this /22. These are ROA invalid, but I accept the prefixes as long as they match the customers IRR derived prefix filters, and they have the NO-EXPORT community attached. The customer has a /22, that is announced to the world, these /24s are for steering traffic within my network only, between the interconnects with their transit provider and their own network, so we don't announce them out further, but we let them TE traffic within our network. Like above, not possible without prefix lists.

There may be different schools of thought on how to approach this, and whether it is something to be solved at all. In general I'd like customers to somehow register their intent in some system before accepting more-specifics that violate the intent they registered in some (other?) system. There also are transit providers that consciously do not offer a 'loophole for TE' because they deem it to be unsafe to implement. YMMV. Perhaps one should devise an API / WebUI to load more-specific prefixes and use that in the generation of SLURM data? And perhaps this is interesting related reading: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-lta-use-cases-06

3. Unused space; as a transit provider, of course people try from time to time to announce prefixes to us for which there is no ROA and there is no route object. They are usually spammers, trying to squat on some unused IP space. If I remove prefix filters and use your approach of accepting unless given a sign to reject, these become RPKI unknown and we would accept them. With prefix filters, these prefixes aren't in the IRR data, so they're rejected.

What's the actual harm in accepting those, if it truly is UNUSED space? Is this not an exception that can be dealt with using post-hoc analytics, must the regular operational path be dilluted to accommodate a rarity? Monitoring your routing tables for RIR-unassigned space and reaching out to customers to ask "hey what's up?" is a good practise.

Above are example of functionality that is lost if we wholesale remove IRR derived data (AS-SETs). Also, I think we can safely assume other networks have other uses cases which I haven't mentioned.

Now let's also consider the security side of things;

* We are years away from rejecting ROA unknowns, because this requires like >95% of prefixes to have a ROA.

The notion of rejecting RPKI ROV-not-found routes is fundamentally flawed. This should not be an objective at all.

* We are years away from rejecting ASPA invalids (let alone unknowns!), because it's not even supported by all major vendors, requires truck roll to upgrade, and operators need to create ASPA records.

ASPA unknowns cannot be rejected. Why are you years away from rejecting invalids? Is that becaus of your choice of vendor? You use Arista, right? Why not load BIRD or OpenBGPD (which both can do ASPA) instead of the BGP daemon that is holding you back?

* We are years away from wide spread RFC9234 adoption; again, not all major vendors support it yet, requires truck roll to deploy it.

Is this 'we (as in industry) or 'we at my $employer'? Because the Internet is already using RFC 9234 in more and more places. It already today is stopping many route leaks. RFC 9234 attributes -right now- are passing through your network. Funny enough, I've already had great success deploying RFC9234 on Arista. So it may be your own choices that are limiting you? And maybe your hands were tied? It may not be necessary to follow the beaten path... but maybe it is! All in all I don't think it would be very accurate to state that 'the industry as a whole is here or here with adoption', given that individual operators oftentimes can _choose_ to make something work. In Dutch there is a saying "waar een wil is is een weg"! :-)

In the mean time, ample tooling exists for IRR derived filters and all major NOSes already support this. Networks could actually make use of IRR derived AS path filters as a stop gap until the above points reach a wider level of adoption and maturity. As Saku mentioned in the other thread here on NANOG, most AS-SETs are actually in good working order,

Where 'good working order' means... "can explode at any moment"? :') Can you please clarify what _exactly_ you mean with 'good working order'? What are the characteristics of a "good working" AS-SET? Do 'good working' AS-SET serve your purposes well up until a certain size? Or are some IRR databases better in some regard than others? It is of course possible I am taking too grim of a view on this information exchange mechanism, but the fundamentals don't look great to me.

and it is the minority that are total garbage. Until the above "replacement" technologies get to where we need them to be; having some prefix filters / AS filters, would actually improve security in the mean time, when compared to not having them, because if you don't have them, all you have is, what... BOGON filters and max prefix count?

We get alerts from bgp.tools on a near daily basis of prefix leaks affecting our network and/or our customers, because people don't have *any* filtering of any sort, but IRR derived filtering could be deployed _now_. If you vendor doesn't support RFC9234 or ASPA, yeah you can start that conversation with them, but it's years away. We don't need to take an all or nothing approach, we can use IRR derived data now as a stop gap until these other technologies get to a point we can remove IRR data, but I don't believe we are at the point that we can fully remove AS-SETs / IRR derived data yet.

Right. What is you and me can do to move the needle just a little bit? Kind regards, Job

I don't want to de-rail, but two of these AS-SET use-cases are extremely frightening and need better solutions.

1. RTBH;

RTBH route hijacks are very real and extremely impactful. We know AS-SETs aren't the right solution because "trust" is unreliable. We can monitor ( https://blog.cloudflare.com/monitoring-as-sets-and-why-they-matter/ ) AS-SET memberships all we want, and in my experience many networks are actually kind enough when asked to remove a bad entry for your ASN, but it's a chore where you're never quite caught up. A new one can always come up and bite you. https://iepg.org/2019-03-24-ietf104/blackholing_reconsidered_ietf104_snijder... is the most promising idea I've seen for making RTBH filtering so far, because, in my opinion, yet-another-rpki-object ( https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-rpki-doa-00 ) is not the answer and won't catch on for RTBH. Coupling the customer's covering route next-hop lookup with the RBTH announcement filtering makes sense to me.

2. TE;

I really dislike these. Are you bypassing origin lookup entirely for the announcements and not doing any ROV on a longer-prefix, just IRR filtering? Allowing this type of TE is a slippery slope. With the current tools we have, your customers need to just sign their /24 ROA along with the /22; we lack the internal vs. external distinction to do anything else. Again, these longer-prefix hijacks are also *very *real and extremely painful if accepted by a large enough AS. -- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare On Fri, Feb 27, 2026 at 2:50 AM James Bensley via NANOG < nanog@lists.nanog.org> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

Hi Job,

I agree with your end goal, but I think your approach is flawed.

I am not trying to be an apologist for IRR derived data, but fully deprecating AS-SETs actually weakens our current security posture, and our current functionality. To be clear, I believe that ROAs and ASPAs are a step forwards, and I am personally, actively, working on RFC9234 and ASPA adoption. But fully removing IRR derived data is a bad idea (your assumption that most AS-SETs are garbage is not true in my experience, it's the minority that are garbage IMO).

Firstly, here are three real world use cases we have which rely on IRR derived data;

1. RTBH; many networks have a ROA for their IPv4 /22 for example. They don't want people to hijack a more specific so they don't create ROAs for 4x /24s, and they don't create ROAs for /22 upto /24. They just create a ROA for the /22. Also they want to be good and only announce a /22, and not be part of the disaggregation problem. At some point my customer is under attack and announces host routes to me, or even say a /24, with the RTBH community. These are ROA invalid. Also, AS path filters derived from IRR data wouldn't allow this because there is no route object for the /32 or /128. To accept these routes I have to skip RPKI validation, and check they are a prefixes this customer is allowed to announce to me using IRR derived prefix lists (i.e., if object exists for /24, allow /24-32) and check the RTBH community is attached. If the route is RPKI invalid and in IRR prefix list and RTBH community is attached, I can accept the prefix and drop the traffic for my customer who is under attack. Without prefix lists everyone needs to extend their ROAs to be "up to 32" and "up to 128", or create ROAs for all their /24s and /48s and lose the ability to black hole host prefixes.

2. TE; same as above, my customer has an IPv4 /22 with a ROA for the /22 exactly. They connect to me in multiple locations and they want to steer traffic between these interconnects with me. They announce the /22 to me, which I announce to the rest of the world. In location A they also announce to me the first /24 from within this /22, and in location B they announce to me the second /24 from within this /22. These are ROA invalid, but I accept the prefixes as long as they match the customers IRR derived prefix filters, and they have the NO-EXPORT community attached. The customer has a /22, that is announced to the world, these /24s are for steering traffic within my network only, between the interconnects with their transit provider and their own network, so we don't announce them out further, but we let them TE traffic within our network. Like above, not possible without prefix lists.

3. Unused space; as a transit provider, of course people try from time to time to announce prefixes to us for which there is no ROA and there is no route object. They are usually spammers, trying to squat on some unused IP space. If I remove prefix filters and use your approach of accepting unless given a sign to reject, these become RPKI unknown and we would accept them. With prefix filters, these prefixes aren't in the IRR data, so they're rejected.

Above are example of functionality that is lost if we wholesale remove IRR derived data (AS-SETs). Also, I think we can safely assume other networks have other uses cases which I haven't mentioned.

Now let's also consider the security side of things;

* We are years away from rejecting ROA unknowns, because this requires like >95% of prefixes to have a ROA. * We are years away from rejecting ASPA invalids (let alone unknowns!), because it's not even supported by all major vendors, requires truck roll to upgrade, and operators need to create ASPA records. * We are years away from wide spread RFC9234 adoption; again, not all major vendors support it yet, requires truck roll to deploy it.

In the mean time, ample tooling exists for IRR derived filters and all major NOSes already support this. Networks could actually make use of IRR derived AS path filters as a stop gap until the above points reach a wider level of adoption and maturity. As Saku mentioned in the other thread here on NANOG, most AS-SETs are actually in good working order, and it is the minority that are total garbage. Until the above "replacement" technologies get to where we need them to be; having some prefix filters / AS filters, would actually improve security in the mean time, when compared to not having them, because if you don't have them, all you have is, what... BOGON filters and max prefix count?

We get alerts from bgp.tools on a near daily basis of prefix leaks affecting our network and/or our customers, because people don't have *any* filtering of any sort, but IRR derived filtering could be deployed _now_. If you vendor doesn't support RFC9234 or ASPA, yeah you can start that conversation with them, but it's years away. We don't need to take an all or nothing approach, we can use IRR derived data now as a stop gap until these other technologies get to a point we can remove IRR data, but I don't believe we are at the point that we can fully remove AS-SETs / IRR derived data yet.

Cheers, James. -----BEGIN PGP SIGNATURE----- Version: ProtonMail

wsG5BAEBCgBtBYJpoVq0CRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3JnJY1Z2o7ZGQmkFhu+NDLn1llZy0rfNagRxTp3 HfS/pI0WIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAh5cP/RWDVdKjHFp3I0mm hwfiwCc7V7fdmM+WbA8YAx0gLoArx2IlX+SrUlhgAq+KcLhVYj2PazEurJtG x4IgtsigwQBrj9gfihcHD8jQ3Xo9+tFuXXfcAFzBefKd1/yEvPMmpQ8fENlv 1J5y4x7edyEhim2KYNMypfZPDbe9WBH3T1HksPb7U1Iij7AaARke24mL68xR IJ5q2ICHpEffKZFPR8FJeJSRYmHhhwfTfrGzFj2pbvU3RSFJhtcc1NCFiSCS 8ecWEzl9ypqhZvcO1Tpo9TeBh6kvAR0wZr2Xn88jvMgB47IDz+kL+uqMsgnq hbRulbWReiMohXsurPCFzHyrcso6hqeXfXFxmbmXC2m1rpGYW4Oh9zbcbkea OgaYWx5qF0Td++8PCpvy4tVsRUIYHq4jW9hBpIzt1rqluH4Dkyy/WbDwV3Ip n3nfasSRuN+/0c1LThvLgqnWz2JzuJp5Ih4Nmss3kyxE+pikbivuW5t/C6Ta BoiQuxlcRCI6WQLAfCQvDm3Mno4Kxsdu7MQdw1IWR8AwJmF2tolasSvv1vBr HObfvb/+TgXPRk/mqAX0nqTnSBu6quWPrRN4lG+dhP/1YD7Fborr1a/DFBtN Ibd4ZsV9AHjmWNgd/Jq+720oXn6RcPuS1Atdf4EA6i1mLmUbD/WCoI58a12W i5xBBAmr =+4n1 -----END PGP SIGNATURE----- _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/I324CY6Y...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Friday, February 27th, 2026 at 15:38, Bryton Herdes <bryton@cloudflare.com> wrote: Hey Bryton

I don't want to de-rail, but two of these AS-SET use-cases are extremely frightening and need better solutions.

I am in agreement with you. I'm not saying they're fantastic, my intent was just to provide some use cases because nobody else has been. I don't like when people make statements without providing either real life use cases and/or real life data, I always try to provide one or the other or both.

https://iepg.org/2019-03-24-ietf104/blackholing_reconsidered_ietf104_snijder... is

Interesting read; maybe Job can clear it up for me... * Slide 8 -> do all these things need to be logically AND'ed together before the RTBH is accepted? * The summary on the last slide seems to suggest "yes" Again, a real world use case that we have... A customer has two connections to us in active/standby or primary/secondary, whatever you want to call it, but traffic always goes to one link. So all the DDoS traffic is going there, it's congested, maybe it's flapping up and down due to BGP timeouts, and the result is that they can't get a BGP update to us over this link to initiate RTBH. They can send us RTBH via the 2nd link, but it's not the best path to them, so in Job's design, would we accept the RTBH route?

...

2. TE;

I really dislike these. Are you bypassing origin lookup entirely for the announcements and not doing any ROV on a longer-prefix, just IRR filtering? Allowing this type of TE is a slippery slope. With the current tools we have, your customers need to just sign their /24 ROA along with the /22; we lack the internal vs. external distinction to do anything else. Again, these longer-prefix hijacks are also very real and extremely painful if accepted by a large enough AS.

I am in agreement that it's not pretty, but also: * How is this IRR filtering less effective than for prefixes which have no ROA? * The idea of creating ROAs for the longer /24s is exactly what people don't want, because that would allow others to hijack a more specific of the /22 (e.g. a /24) and that hijack would be RPKI valid! As far as I can see, the problem here is that with the current tooling we have there is no "optimal way"; one can optimse for A at the sacrifice of B, or one can optimise for B at the sacrifice of A. Cheers, James. -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsG5BAEBCgBtBYJposKGCRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3JnQ4jCLc88wSiojK4+NW72afIJr1+jUIIT+x+U qmK/Hx4WIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAHSAQAKHYygHn/6NF7G2f 8s9dFLc5XVmgw9klRi6l8+3E4glBqrcAf/jOmrnRST3C1RbEo+OQsAdJP5YO gMfmZQglJZwbcAMI4FMdvjWEvdxqiJyZouEe3zRQ6FF28qpHNf9njlia7ZSl 0aBkj6tctiW9VQCgAmz6piInZhBhslIDg1ycIxkZotwt93MjsKjntjwfgDdc n0yeEI+GnNsoi78V8FFvGgfBgJ7ne3H9ey4bSzV+MxjOiVT80Rc7D01eaJUf tYS0X/FEp27h43Xj33cIHRaT2paDJddS1yClHZ5M1bEESNFcoHEJjvye1NAv s4fPf2m1BKZBu+UODc4drO2wmKe8ohNF0ec+jtPq3cQA/aDoeibXiOm+pu4i qhUwWAz+8XWhDhv4556Ghf98YF/J4SmUCjgOYDEYFaHLPuxqlJoVx1n/ETFE k/RuQxSSXlH4nUFGNpEFMHUcabqDO6t2n53I+4WjmZuqe/diodqm0L3EZEnP cIw9YtemuJ7htwuiNyjp7tfcJekfNcKJ0I+NIwTEK846lZZcLMmMKtEESIoB VC86y7/+rRPVh42FMVfwbwc+ab1+4T95cvEs2QzDNwkLBj574qY/v6P2Ol9k 3hN6SGohIuisKS44IGdxSTLMNYc5m1H1Fo3OHzfWZS0Nw4mgGIxIDzedRISU fwE/igEW =Zyu2 -----END PGP SIGNATURE-----

Active path verification is dicy. - you can have multiple active paths, depending on POV - but if you receive more-specific paths, you will likely collapse to 1 POV - is blackhole desirable for all POV? Now you are blackholing everywhere, instead of the 1 active port. Above issue has happened to us, where the source would not have wanted the blackhole to appear. Even without this problem, it's not entirely clear if the middle ASN generated blackhole is desirable or permitted by the source ASN. Perhaps if middle ASN thinks it should have this control over source ASN, they need to cooperate to figure out how to gain this capability. Either additional ROA or some mechanism between middle and source for source to generate it as needed. So perhaps RPKI-valid-of-more-specific is safer. On Mon, 2 Mar 2026 at 12:27, Job Snijders via NANOG <nanog@lists.nanog.org> wrote:

Hello James,

On Sat, Feb 28, 2026 at 10:25:26AM +0000, James Bensley via NANOG wrote:

...

...

I don't want to de-rail, but two of these AS-SET use-cases are extremely frightening and need better solutions.

I am in agreement with you. I'm not saying they're fantastic, my intent was just to provide some use cases because nobody else has been.

Yes, and in context of this discussion it probably is incumbent on you to provide such details :-)

...

...

https://iepg.org/2019-03-24-ietf104/blackholing_reconsidered_ietf104_snijder...

is Interesting read; maybe Job can clear it up for me...

* Slide 8 -> do all these things need to be logically AND'ed together before the RTBH is accepted? * The summary on the last slide seems to suggest "yes"

The summary on the last slide is key!

Seven years ago, I intended to convey that perhaps the validation of customer requests for traffic blackholing should be reconsidered: rather than constructing a separate set of filters distinct from 'normal routing', the act of honoring blackholes should be made contigent on whether IP traffic is even being forwarded at all to the requesting customer. Now, if I were to re-create these slides in 2026, I would drop the "did you register the destination in IRR" bullet point. :-)

So, this slidedeck should be considered a tabletop exercise, rather than something you can take and verbatim deploy. Implementing the spirit of this slidedeck will require a modest effort to build some software.

...

Again, a real world use case that we have...

No worries, Network Engineers Without Borders to the rescue!

...

A customer has two connections to us in active/standby or primary/secondary, whatever you want to call it, but traffic always goes to one link. So all the DDoS traffic is going there, it's congested, maybe it's flapping up and down due to BGP timeouts, and the result is that they can't get a BGP update to us over this link to initiate RTBH. They can send us RTBH via the 2nd link, but it's not the best path to them, so in Job's design, would we accept the RTBH route?

I will offer some tangible suggestions for your consideration on how to implement RTBH validation in a way that does not depend on IRR data. See, I am not against using lists of prefixes in the router's configuration, I'm merely advocating that prefix lists used to validate blackholes probably shouldn't be constructed using IRR-derived data (because that IRR data is arbitrary unsigned data of unknown provenance).

When validating, what's important is whether the customer ASN is the next-hop AS (the active path), it is not so relevant which of their IP next-hops exactly is/was the active one in case there are multiple interconnections between your network and the customer network.

STEP 1: RECORD ALL BLACKHOLE REQUESTS IN MRT FORMAT

eh... no, scratch the above. If one starts recording, might as well record it all. :-)

STEP 1: JUST RECORD ALL BGP UPDATES RECEIVED FROM CUSTOMERS IN MRT FORMAT

I consider it good practise for (transit) ISPs to record BGP messages, in order for operators to be able to post-hoc debug issues such as BGP hijacks or unauthorized blackholing. A simple implementation would be to have all the BGP routers peer with a central route collector and configure the route collector to write the received messages in MRT format to durable storage.

STEP 2: USING A SLIDING TIME WINDOW, USING THE MRT DATA FROM STEP 1, CONSTRUCT A LIST OF IP PREFIXES, PER CUSTOMER, FOR WHICH THE CUSTOMER WAS THE ACTIVE PATH

The operative theory here is that if the customer somehow managed to become the active path for 'normal routing' (e.g., your routers actually forwarded IP traffic to the Customer's AS somewhere in the last 12 or 24 hours), they have gained the privilege to instruct your network to discard IP traffic in their behalf. "Normal routing" can be protected using RPKI ROV, ASPA, RFC 9234, Peerlock, Maximum Prefix Limits, etc.

Of course, if a customer wasn't using your network for reachability, then their requests for IP blackholing should be considered "already fullfilled": your network wasn't sending them IP packets destined for the IP to be blackholed anyway.

The concept here is that the "blackholing service" provided by many transit providers isn't so much that forwarding of traffic for a given IP destination must completely cease within the transit provider's network, but rather that the transit provider is requested not to deliver that IP traffic across the customer's port.

In other words: blackholing offered by IP transit providers is not a global censorship tool, it is a facility of last resort to attempt to reduce collateral damage.

STEP 3: UPLOAD THE CONSTRUCTED PREFIX LISTS AS CUSTOMER-SPECIFIC PREFIX-LIST FILTERS FOR BLACKHOLING.

Your (publicly documented?) routing policy could be to permit customers to request blackholing, provided that they were on the active path for the given IP destination at some point in the last 12 or 24 hours. The exact timing paramters should be subject to further research.

STEP 4: REPEAT THE ABOVE EVERY FEW HOURS.

Kind regards,

Job _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GVXS6PMK...

-- ++ytti

On Mon, 2 Mar 2026 at 15:09, Job Snijders via NANOG <nanog@lists.nanog.org> wrote:

I would benefit from a few more words on what exactly you mean with the above. Do you mean to say that if the customer AS is 65535, you'd only permit blackholes if they are contained within the prefixes for which AS65535 is an authorized origin, according to RPKI ROAs? Sure, that seems a reasonable precaution.

Yes. Sort of pretending ROA allowed to /32 or whatever the specific may be, IFF there is a blackhole community attached. Ignoring active path. -- ++ytti

Some additional negatives of building prefix-lists out of AS-sets and route objects: * AS-sets make it impossible for ASes to specify different sets of prefixes that they intend to announce to different neighboring networks. Each ASN only maps to a single set of route objects. A possible byproduct is that ASes may specify (a single) loose filter to (all) their neighboring networks. * Route objects cannot specify prefix-length ranges. This complicates the management of route objects. For example, if one has a /44 IPv6 prefix that they need to announce at /48 granularity, they have to maintain 16 route6 objects. * To aggravate the above, bgpq4 does not generate range-based filters when building prefix-lists by default (but you can pass -A for that). This results in prefix lists that are larger than necessary. I bet the routers optimize with aggregation or it would be a gigantic slog, but the shorter list is still preferable for inspection. * There is limited, if any, validation of route objects for prefixes without an ROA. I wish peers would use RS-PEERING-TESTBED instead of AS-PEERING-TESTBED... On Thu, Feb 26, 2026 at 6:41 AM Job Snijders via NANOG <nanog@lists.nanog.org> wrote:

Dear all,

Securing one's EBGP perimeter is a challenge: how to do it?

(Some slides: https://bsd.nl/publications/irr_out_rpki_in.pdf)

Much of the information used to construct safe pass/nopass EBGP filters comes in unwieldly formats and from questionable provenance. I can share some detail of the approach I implemented at my previous $employer, perhaps it'll help some of you get rid of excessively large IRR-based prefix-filters! :-)

Quick recap - here is what we're protecting against:

A) Mis-originations (the digits on your keybaord are super close to each other) B) Unauthorized more-specifics (e.g. some government instructs their incumbent telco to kill access to 1.1.1.1/32 or some other IP) C) Route leaks (an operator turns up a second EBGP session on their non-RFC8212 router and BOOM, a route-leak could spring into existence)

What doesn't work well: generating an 'allowlist' (a prefix-list-filter) by recursing a given IRR AS-SET into its members and doing reverse lookups to obtain the set of "route:" "route6:" objects to construct a list of prefixes. The core problem is that any AS-SET can reference any other AS-SET and the resulting excessively large lists of prefixes are a PITA to upload to routers AND WORSE: are a very expensive "allow any any".

What I've found to work quite well:

- Imposing good ole' maximum prefix limits: when a peer or customer starts announcing 100x or 1000x the number of routes they normally announce, usually something somewhere is wrong and it is safer to automatically terminate the EBGP session. This safety mechanism helps with issue (C)

- "BGP OPEN Roles" (RFC 9234 / OTC attribute). This is a safety mechanism (perhaps surprisingly) does _not_ rely on either IRR or RPKI. RFC 9234 is extremely easy to implement and deploy. The trick is that both sides of the EBGP session have to agree with each other what they are to each other (in context of the Gao-Rexford model [1]). It is opportunistic: if one side doesn't support it, the other side can still do its part. At Fastly this helped identify and resolve a bunch of configuration issues in peering sessions, and it stopped a lot of leaking, even with very limited global deployment! At YYCIX we saw it stop IX-to-IX leaks while the networks in the middle didn't even support it (yet) [2]. The BGP OPEN Roles mechanism offers per-EBGP-session-per-NLRI granuarlity and greatly helps with issue (C).

- The practise of rejecting RPKI-ROV invalid routes is effective for addressing issues (A) & (B). This practise is popular amongst large carriers and IX route server operators. Even though there are hundreds of thousands of ROAs in the global system, loading those into routers is a breeze: the binary RPKI-To-Router (RTR) provisioning protocol is quite effortless compared to using TCL to upload megabytes of prefix-filter in the vendor-specific language.

- 'Peerlock' [5] / 'peerlock-lite' [6] : when you as operator _know_ that certain ASNs should NEVER appear anywhere in the AS_PATH behind certain EBGP sessions, why not just outright block those? Proven tech albeit a bit involved to deploy and maintain, so a spiritual successor appeared: ASPA

- ASPA very much helps with issue (C). There already are more than a 1000 AS holders [7] who publicly declared what the ASNs of their authorized upstream are. From this information it can be inferred what paths are plausible and which paths are not plausible. Implausible paths are rejected (just like you'd reject ROV-invalids). ASPA uses the same pipelines as are used for ROAs, so we capitalise on previous investments. ASPA can easily be deployed on IX route servers using open source BGP implementations [8], and most major commercial hardware chassis-oriented vendors have it on their roadmap.

In summary: use maximum prefix limits, reject ROV-invalid & ASPA-invalid routes, take advantage of the RFC 9234 OTC attribute, and maybe use Peerlock. Stop using IRR-based prefix-lists. IRR needs to be sunset.

Vendors can help their users: for example, in the OpenBGPD implementation the 'role' configuration keyword helps set up *both* ASPA and RFC9234 in one go! This is super convenient for the operators.

If the above guidance is followed, the resulting router configurations are VERY concise and don't require a lot of ongoing maintenance (because the parts of the config that frequently change are provisioned through RTR); but most importantly, these practises greatly help improve the safety and reliablity of day-to-day routing operations.

Kind regards,

Job

[1]: https://people.eecs.berkeley.edu/~sylvia/cs268-2019/papers/gao-rexford.pdf [2]: https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DX3HDX2E... [3]: https://bgpfilterguide.nlnog.net/guides/reject_invalids/ [4]: https://www.kentik.com/blog/how-much-does-rpki-rov-reduce-the-propagation-of... [5]: https://arxiv.org/abs/2006.06576 [6]: https://bgpfilterguide.nlnog.net/guides/no_transit_leaks/ [7]: https://console.rpki-client.org/aspa.html [8]: https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TB3IN5DD... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LHXZO7FK...

Hi. A short follow-up. I noticed that newer Junos releases allow to install validation records from a specific RTR session to a designated named validation database and, for example, this enables a setup where RTBH prefixes are not rejected if the RTR sessions for RTBH routes are down. I modified the script generating the JSON file for RTRTR in a way that routers always have "0.0.0.0/0-32 ASN 0" and "::/0-128 ASN 0" validation records besides possible /32 v4 and /128 v6 RTBH validation records in validation database named "rtbh". The RTBH check in the BGP import policies list was moved back before the RPKI check. As an example, the RTBH check for v6 can be seen below: root@vjr-17> show configuration policy-options policy-statement ipt-rtbh-v6 term reject-blackhole-rpki-invalid { from { family inet6; protocol bgp; community blackhole; validation-database-instance { database-name rtbh; state invalid; } } then { validation-state invalid; reject; } } term accept-blackhole-rpki-valid { from { family inet6; protocol bgp; community blackhole; validation-database-instance { database-name rtbh; state valid; } } then { local-preference 170; validation-state valid; origin igp; /* requires accept-remote-nexthop */ next-hop 100::1; accept; } } /* fallback if RTBH RTR sessions are down */ term accept-blackhole-rpki-unknown { from { family inet6; protocol bgp; community blackhole; validation-database-instance { database-name rtbh; state unknown; } route-filter ::/0 prefix-length-range /128-/128; } then { local-preference 170; validation-state unknown; origin igp; next-hop 100::1; accept; } } term reject-blackhole { from { family inet6; protocol bgp; community blackhole; } then reject; } then next policy; root@vjr-17> In summary, if the v6 blackhole prefix does not have a /128 entry in "rtbh" validation database, then it will be rejected thanks to "::/0-128 ASN 0" VRP. If the validation check is valid or unknown, then the /128 blackhole prefix is accepted. I uploaded the configuration files here: https://gist.github.com/tonusoo/3e3cc16fe2008fcb9b47aa6e4831c73d Martin