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

[Job Snijders via NANOG <nanog () lists nanog org>]

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_snijders.pdf

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
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/UL2NDYL2OBBSZ3XNULVLJLPOBQ32MU4P/