Re: Securing EBGP while getting rid of big IRR-based prefix-list-filters (Was: How long AS-PATH policies have you used)

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_snijders.pdf
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 <
[email protected]> 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/[email protected]/message/I324CY6YLKEEV74GJOU6CLBY4DZJEYZJ/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/JVZRAWOKUYISAK3V64CVQL4M7PZEBNEQ/