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

[James Bensley via NANOG <nanog () lists nanog org>]

-----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-----

Attachment: publickey - lists+nanog@bensley.me - 0x3E936359.asc.sig
Description:

_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/I324CY6YLKEEV74GJOU6CLBY4DZJEYZJ/