Re: [anti-abuse-wg] [routing-wg] An arrest in Russia
Hi, On Fri, Jan 03, 2020 at 04:14:07PM +0000, Suresh Ramasubramanian wrote:
So the RIR has absolutely no role in maintaining say IRR data? I agree validating LOAs and such for routing changes would be on providers. Though if the changes were to be made in IRR data who would validate it?
IRR data is authenticated by registry data in RIPE land, if the resource holder chooses so. Short story. So, nobody can create routes for, say, my address space unless I authorize that. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
In message <20200103165918.GL72330@Space.Net>, Gert Doering <gert@space.net> wrote:
On Fri, Jan 03, 2020 at 04:14:07PM +0000, Suresh Ramasubramanian wrote:
So the RIR has absolutely no role in maintaining say IRR data? I agree validating LOAs and such for routing changes would be on providers. Though if the changes were to be made in IRR data who would validate it?
IRR data is authenticated by registry data in RIPE land, if the resource holder chooses so. Short story.
So, nobody can create routes for, say, my address space unless I authorize that.
Yes. Nowadays, the RIPE IRR is better in this respect than any other IRR that I am aware of. Don't even get me started about RADB! They don't check anything, and there are stale entires in there from 10+ years go for routes to bogons. As far as I can tell, there is zero quality control and zero maintenance, the result being that it has become one big playground for routing crooks. Regards, rfg
On Fri, Jan 03, 2020 at 01:40:41PM -0800, Ronald F. Guilmette wrote:
In message <20200103165918.GL72330@Space.Net>, Gert Doering <gert@space.net> wrote:
On Fri, Jan 03, 2020 at 04:14:07PM +0000, Suresh Ramasubramanian wrote:
So the RIR has absolutely no role in maintaining say IRR data? I agree validating LOAs and such for routing changes would be on providers. Though if the changes were to be made in IRR data who would validate it?
IRR data is authenticated by registry data in RIPE land, if the resource holder chooses so. Short story.
So, nobody can create routes for, say, my address space unless I authorize that.
Yes. Nowadays, the RIPE IRR is better in this respect than any other IRR that I am aware of.
I'd like to offer some additional datapoints, in this context I consider an IRR (either by a RIR or NIR) 'validated' if "route:" objects can only be created with the consent of the then-current resource holder. Current RIRs: * All RPKI ROAs (under all of the five RIRs) are validated * RIPE NCC's "RIPE" IRR source is validated (but "RIPE-NONAUTH" is not). * APNIC's IRR source "APNIC" is 100% validated * AFRINIC's IRR source "AFRINIC" is 100% validated Current NIRs: * NIC.BR's "whois" registry (which contains routing data) is validated * JPNIC (who manage 'JPIRR') validates all route objects on a regular interval There are more NIRs, but not all of them have IRRs, or in some cases the IRR function has been outsourced back to the RIR. Near Future: * LACNIC is working on a "RPKI to IRR" bridge, which will bring a new RIR managed IRR source to the ecosystem, but it will be 100% validated since it is based on RPKI. * ARIN is working on a validated IRR, I myself am involved in this project to help achieve the best possible outcomes. So in short: the RIPE IRR is very good. There are more IRRs like it already today. And the remaining RIR IRRs are moving to a more secure service execution model.
Don't even get me started about RADB! They don't check anything, and there are stale entires in there from 10+ years go for routes to bogons. As far as I can tell, there is zero quality control and zero maintenance, the result being that it has become one big playground for routing crooks.
As mentioned before, third party IRRs - through the IRRd 4 project - are working to address such shortcomings. Ronald as expressed some concern with the pace at which these projects are moving along, but I'm not sure things can be sped up - and I personally appreciate the positive direction in which things seem to be developing. Kind regards, Job
In message <20200103215429.GF93721@hanna.meerval.net>, Job Snijders <job@ntt.net> wrote:
{... snipped ...}
My apologies to Job, and to everyone, for my somewhat hasty and improper generalizations about non-RIPE IRRs generally. We agree that the RIPE IRR is at present very good, but my comments could certainly be read/misconstrued as me casting unwarranted aspersions on all others, which I quite clearly should not be doing. Many others are doing a fine fine job of vetting things and providing very accurate data also. That having been said, I cannot resist the temptation to poke at this one bit of relevant information that Job shared:
Current RIRs:
* All RPKI ROAs (under all of the five RIRs) are validated * RIPE NCC's "RIPE" IRR source is validated (but "RIPE-NONAUTH" is not). * APNIC's IRR source "APNIC" is 100% validated * AFRINIC's IRR source "AFRINIC" is 100% validated
That last one is a bit problematic, as I hope and trust everyone here now knows. I have been waiting for the right moment to note that although RPKI has been widely touted, including by myself, as the thing that will in future save us all, it isn't quite the ultimate and perfect solution for routing security, at least not if it turns out that the folks who sit at the roots of the trust linkages cannot themselves be trusted. But I suppose that this is an entirely superfluous observation for me to offer up. Everyone who even vaguely understands chains of trust and their relationship to routing, as I do, vaguely, will have already grasped this rather obvious point. Meanwhile, on the other side, folks who lack even a vague grasp of the RPKI trust model won't be enlightened just because I said what I just said. Regards, rfg
On 3 Jan 2020, at 22:41, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
I have been waiting for the right moment to note that although RPKI has been widely touted, including by myself, as the thing that will in future save us all
Who claimed this? What a strange thing to think. Nick
In message <06D65075-1380-47D2-A71B-A85216B7E42D@foobar.org>, Nick Hilliard <nick@foobar.org> wrote:
On 3 Jan 2020, at 22:41, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
I have been waiting for the right moment to note that although RPKI has been widely touted, including by myself, as the thing that will in future save us all
Who claimed this?
What a strange thing to think.
Well, RPKI quite certainly beats the hell out of the nothing that we have had in its place for lo these many years now. I certainly believe that in the absence of any malfeasance at any of the RIR, it -will- bring order to chaos in te world of routing, when and if adoption becomes universal or nearly so. Regards, rfg
Ronald F. Guilmette wrote on 03/01/2020 23:50:
Well, RPKI quite certainly beats the hell out of the nothing that we have had in its place for lo these many years now.
having used irrdb prefix filtering in production for many years, I respectfully disagree.
I certainly believe that in the absence of any malfeasance at any of the RIR, it -will- bring order to chaos in te world of routing, when and if adoption becomes universal or nearly so.
No, it won't. RPKI in its current form provides an insulation layer which stops certain types of misorigination problems and mitigates others, but has almost no impact on the wider question of policy routing. RPKI also works quite well from the point of view of incremental deployment, i.e. it's not necessary to aim for universal or near-universal adoption. Policy routing is difficult. We tried to fix it years ago with RPSL and that failed. There have been several attempts to look at this since then but they've all floundered because it's a fundamentally complex problem which involves a lot of different areas including policy management, i.e. codification of human judgement; deployment of this policy to networking equipment which doesn't have the hooks to implement this at scale; how to accurately model a routing policy right down to igp / egp interaction so that you have a balance between enough scope to describe routing policy at a per-router, per-peer-address, per prefix level, but at the same time not making it so complex that people would be scared away from implementing it reasonably; and many other things. RPKI aims to address some specific problems relating to mis-routing - cherry picking, if you will - and to provide a 90% solution for those problems. Nick
RPKI in its current form provides an insulation layer which stops certain types of misorigination problems and mitigates others, but has almost no impact on the wider question of policy routing.
RPKI also works quite well from the point of view of incremental deployment, i.e. it's not necessary to aim for universal or near-universal adoption.
Policy routing is difficult. We tried to fix it years ago with RPSL and that failed. There have been several attempts to look at this since then but they've all floundered because it's a fundamentally complex problem which involves a lot of different areas including policy management, i.e. codification of human judgement; deployment of this policy to networking equipment which doesn't have the hooks to implement this at scale; how to accurately model a routing policy right down to igp / egp interaction so that you have a balance between enough scope to describe routing policy at a per-router, per-peer-address, per prefix level, but at the same time not making it so complex that people would be scared away from implementing it reasonably; and many other things.
RPKI aims to address some specific problems relating to mis-routing - cherry picking, if you will - and to provide a 90% solution for those problems.
just in case anybody is wondering, i think nick is about right here except, i think the above is actually about rpki-based origin validation, aka rov, not the rpki, which is a database randy
In message <e7d0097b-68ea-be04-039b-1135cd802c04@foobar.org>, Nick Hilliard <nick@foobar.org> wrote:
Ronald F. Guilmette wrote on 03/01/2020 23:50:
Well, RPKI quite certainly beats the hell out of the nothing that we have had in its place for lo these many years now.
having used irrdb prefix filtering in production for many years, I respectfully disagree.
All I can say is that if RADB is or has been one of your data sources, then you have been relying on data that is quite often (and demonstratably) wrong. I won't argue your other points, since you clearly know one heck of a lot more about these things than I do. I will only reiterate that RPKI, or at least my understanding of it, appears to be way better than basing routing decisions on a data base where any charlatan can inject anything he wants, any time he wants. Regards, rfg
participants (5)
-
Gert Doering -
Job Snijders -
Nick Hilliard -
Randy Bush -
Ronald F. Guilmette