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