Re: [routing-wg] Routing Reg. mess [was: Re: [anti-abuse-wg] Fwd: Hijack...]
I think that it is wrong to exclude use of the RPKI signed assertion of authority over a resource to drive admission of foreign records. I do not speak to RPSL per se or ROA, but the fact is that maintainer status is not visible in routing and is irrelevant. Databases need ACL and admission control but we all know the RIPE code has (and always has had) a privileged channel which can effect change in the contents of the schema without first class use of the authorization primitives: heck you can type SQL commands directly and make objects So I like much of what Wilfred said in terms of its intent and outcome. I do not agree that ab initio we should reject use of RPKI signed objects to permit import and export of external information. If I sign an authorization to somebody to include my resources in their IRR, and my resources are in the certificate which signed that authorization what can be stronger? -G On 14 November 2014 06:59, Elvis Daniel Velea <elvis@velea.eu> wrote: > Hi Wilfried, > > finally someone responding to the problem presented. I was about to > think that nobody cares anymore. > > On 14/11/14 16:18, Wilfried Woeber wrote: > > Michael Horn wrote: (to anti-abuse-wg@ripe.net) > > > > [...] > > > >> will result in significant workload. Holy dingus, is this database a > mess... > > And not just "this" one. The whole "Routing Registry" stuff is an > incredible > > mess, and since years, actually. Not really a Numbers Registry failure > or a > > negligence, but rather a multi-faceted mesh of FUD, History and Trade > Secrets > > claimed. > > > > Let me try to collect some facts, at least according to my memory. > > Please correct me where I'm wrong... > > > > - not all 5 RIRs actually do support an IRR functionality. > > > > - the RPSL doc.set, back in the good old days, had some ideas and > provisions > > for integrating the 5 (or then, rather 3, iirc) pieces of Numbers > Registries > > into a single, global, consistent structure. > > As Gert put it: it didn't fly. > > Since then, we were putting band-aid over patch over whatever to deal > with > > that. The result is what we have before us, right now. > > > > - the whole system of creating objects, at least in the RIPE Region, has > become > > totally inconsistent. For an address block, where the RIPE DB is > authoritative, > > and an AS number, you need the credentials from both parties to > register a route: > > or route6: object. > > > > for out-of-region authoritative entries, the dreaded maintainer was > created, in > > order to provide the (useless) 2nd auth: token. > > > > For the RPKI stuff, again, there isn't a requirment for a second > authentication > > token, iirc not even a *notification* to the AS ref.d, when an RoA is > created. > > Anyone of you still thinks RPKI is going to be helpful here? > > Bah, it's just going to give another false impression of credibility > + new vectors > > for errors and attacks. > > > >> -mh > > The only way(s) forward I can see are: > > > > - require manual approval of route: objects for the case of > out-of-region registrations > sounds like an other patch, one that I would welcome as a temporary > solution. > > > > - get the RPSL flaws fixed, the RFCs updated and then implemented > this will probably take years.. > > > > - integrate the 5 Number Registries into a homogenous, distributed DB > with consistent > > authentication mechanisms > > > > - come up with a viable proposal for 1 (one!!) global routing registry > that is > > authoritative, up-todate and complete, used by all operators (yes, I > know, it is > > the wrong type of year /w a XMAS) > I've been asking myself for years why the RIRs can not, under the NRO, > ASO, IANA, (?) umbrellas to come up with a unique registry (resource + > routing).. It's not like the communities do not want/need it... Do we > need to pass a global policy to ask the RIRs to work together? :-) > > A single source of information is, at this moment, a dream. > > - try to do any or all of the above and do so without RPKI requirements. > Please! > > > > Wilfried. > > > regards, > elvis > >
Dear colleagues, A few observations: - RIPE NCC has operated RIPE IRR as an open IRR based on community requirements for years. In my opinion, a very productive first step towards better data quality and maintenance of RIPE IRR is for the community to provide RIPE NCC with an operations policy for RIPE IRR. At the moment there is no policy governing RIPE IRR, so even in case of clearly fraudulent route objects -specially for resources outside of RIPE Region- RIPE NCC has no guidance on how to proceed and the records ultimately stay there. Having some policy, no matter how lightweight it is, will have great effect on improving things. This was brought up in Routing-WG session in London and echoed in RIPE Database-WG as well and I strongly suggest the community to take action in that regard. Here at RIPE NCC we are keen to provide any help required in that regard. - Now, into the issue of open IRRs. For RIPE Region resources, the process has enough clarity and there is authentication/authorisation in place. Although that can be improved -as it was suggested by RIPE NCC and a few members on different occasions- the data quality for out of the region objects are much lower and there is basically no auth. present. Current model, as it has always been, is a first-come first-served model where you can basically register any out of region resources in the public IRR and the objects will stay there, locking others who might want to change things. - 4 out of 5 RIRs run IRRs. A simple solution would be to limit each IRR to RIR’s managed resources. However this solution has a few flaws and might have a negative impact: * Many operators only look into RIPE IRR and/or RADb and ask their users to register their routes in one of these databases before they can serve them, no matter in which region they are located. This might not be the best practice but it is the reality. Looking at IRR query load, RIPE Database IRR by far surpasses other RIRs routing databases. This means, restricting RIPE IRR might have a negative effect on documentation of routing data: I expect instead of changing process, operators might drop the requirement. * In many cases the ASN comes from one region and IP Prefix comes from another. Requirement from some IRRs (including RIPE’s) to include auth. for both ASN and IP Prefix only makes things more complex, specially if there are more restrictions. * Routes for many early registration and legacy resources from different regions are only documented in RIPE IRR. This includes critical information like route objects for most of Root DNS operators. These points should be considered when thinking about a solution. - The idea of having a single repository has been brought up a few times. Although it might be possible (very complex though, specially for users, because of different policies of each region) I personally don’t see the benefit in that. RIPE Database for example, already has a complete and consistent view of global registration and routing data, presented as GRS. So, if a user desires, they can query only RIPE database to get information about any resources. New technologies like RDAP (which is implemented by all RIRs) also address this issue as a user can query any RIR registry and get information in a single, well defined format. - There are many technical possibilities to improve things and we have many smart people in our community who have already proposed solutions to fix issues. One thing to keep in mind is most of these solutions are transitional solutions and each of them can incrementally improve things. It is possible to interlink RIR auth. systems, it is possible to interlink RPKI and IRR, it is possible to mark resources with an auth. quality indicator, etc. The main question then becomes effectiveness, as almost all IRR data users with automated processes rely on IRRtoolset which doesn’t consider any of this new changes or many of documented RPSL features. So, solutions should either rely on improving quality of inserted data AND consider the enduser toolset capabilities and improvements. Have a nice weekend, Kaveh. --- Kaveh Ranjbar, Chief Information Officer, RIPE NCC.
In message <B258521A-B403-4987-8860-5A7DF2CAE1E7@ripe.net>, Kaveh Ranjbar <kranjbar@ripe.net> wrote:
- RIPE NCC has operated RIPE IRR as an open IRR based on community requirements for years. In my opinion, a very productive first step towards better data quality and maintenance of RIPE IRR is for the community to provide RIPE NCC with an operations policy for RIPE IRR. At the moment there is no policy governing RIPE IRR... ... * Many operators only look into RIPE IRR and/or RADb and ask their users to register their routes in one of these databases before they can serve them, no matter in which region they are located. This might not be the best practice but it is the reality. Looking at IRR query load, RIPE Database IRR by far surpasses other RIRs routing databases...
Please forgive me. I am ignorant of much or all of the history relating to these matters, so your comments are both highly educational and highly appreciated, by me, at least. But I'm still trying to wrap my arms around what, it seems, you just said. If I have understood you correctly, you are saying that RIPE NCC has, for some very long time now, been operating its own IRR with -zero- guidance or instructions on how to do that from the community, -and- that this IRR... constructed and maintained with -zero- community input or guidance... has become, within its lifetime, the defacto ``standard'' IRR for the all of planet earth??
This means, restricting RIPE IRR might have a negative effect on documentation of routing data...
You say that like its a bad thing. With respect to the various routes hijacked by AS201640, I think that the world would have been a better place if the RIPE IRR had not, in effect, endorsed the legitimacy of those. (Note that this veneer of legitimacy was also subsequently imported into the MERIT RADb... from RIPE.)
* In many cases the ASN comes from one region and IP Prefix comes from another. Requirement from some IRRs (including RIPE's) to include auth. for both ASN and IP Prefix only makes things more complex...
Welcome to the 21st century! Life is complex. I don't believe that it becomes less complex if we simply try to sweep the complexity under the carpet, e.g. by performing only incomplete and clearly inadequate verification of the legitimacy of route objects being added into the data base.
It is possible to interlink RIR auth. systems, it is possible to interlink RPKI and IRR, it is possible to mark resources with an auth. quality indicator, etc...
As I attempted to point out in my prior two postings, the things you just mentioned, while perhaps admirable for other reasons, all seem to me to be technological overkill when it comes to solving what is, at base a quite simple problem, i.e. obtaining the consent/endorsement of the actual IP block registrant before a route object is entered into the RIPE IRR data base. That consent/endorsement can be obtained, via a simple automated process, essentially identical to the one used for signups to this very mailing list, where the request for approval is e-mailed to the contact e-mail address for the IP address block in question. If this simple solution would not have worked to thwart the malevolent ill intent of AS201640 with respect to the RIPE IRR, or if it would be at all difficult to implement, then I, for one, would appreciate it very much if you would explain why. Regards, rfg
In message <CAA=nHSJt9cjU2vt+Zb=n-=w1AHBqMH_4TZ=DuL5VpWZ8N3HTQg@mail.gmail.com> George Michaelson <ggm@apnic.net> wrote:
I think that it is wrong to exclude use of the RPKI signed assertion of authority over a resource to drive admission of foreign records.
I would hate to see... as the old saying goes... the perfect being the enemy of the good. I personally don't know a damn thing about RPKI, other than the fact that it involves some fancy schmancy crypto stuff, and crypto stuff can be made highly secure (which is quite obviously a Good Thing). However over on the anti-abuse mailing list there seems to be at least one fellow... a RIPE member... who seems to loath and despise RPKI. I don't know enough to understand the exact reasons for this. I don't know and I frankly don't care. I just worry that he may not be alone, and that the implication of that possibility is that RIPE will be unable to establish a consensus that RPKI should be required, universally, going forward. I fancy myself a pragmatist. I'll be happy with _any_ solution that works. As I just noted in my prior posting here, it seems to me that a simple e-mail confirmation process which involves the registrant of the IP block for which a new route object is being requested would solve the problem entirely, even while side-stepping the (perhaps politically contentious) issue/question of an enforced universal use of RPKI. If I'm wrong about that, please describe to me how. Regards, rfg
participants (3)
-
George Michaelson -
Kaveh Ranjbar -
Ronald F. Guilmette