Hi Eric, Technical possibility does not mean that you can force it to be implemented. While there are related documents for legacy resources for example, not all the legacy resource holders not having any relationship with RIPE NCC will abide the rules. On the other hand not all RIPE NCC members seem to interested in RPKI as there is always a question on trusting, treats and local law. Personally me is against using this mechanism. Regards, Vladislav -----Original Message----- From: Erik Bais [mailto:ebais@a2b-internet.com] Sent: Monday, November 10, 2014 4:54 PM To: Potapov Vladislav; routing-wg@ripe.net Subject: RE: [routing-wg] FW: discussion about rogue database objects Hi Poty, In the RIPE region all resources are allowed to be signed for RPKI. Policy 2013-04 ( Resource Certification for non RIPE-NCC Members) - http://www.ripe.net/ripe/policies/proposals/2013-04 Status : Accepted and implemented. That allows all IP resources to be used under RPKI within the RIPE region for registered resources, if there is a contractual agreement between the resource holder : For PA : valid SSA for LIR membership For Legacy : Signed agreement as described under RIPE-605 (http://www.ripe.net/ripe/docs/ripe-605 ) explaining how to do so. Like signing the actual Terms and Condition for an LIR who has legacy space and wishes to import their Legacy space into the LIR portal for ease of administration and usage of RPKI. ( Ripe document RIPE-616 ) For PI space : Signed End-User Agreement between RIPE NCC, the Sponsoring LIR and the End-User holder of the resource. I don't know what the status is specifically for other RIR's in terms of their acceptance for RPKI for non-members. ( legacy holders or PI space ) But we (RIPE community) are ready for it from a policy point of view as far as I see it. Regards, Erik Bais -----Oorspronkelijk bericht----- Van: routing-wg-bounces@ripe.net [mailto:routing-wg-bounces@ripe.net] Namens poty@iiat.ru Verzonden: maandag 10 november 2014 14:08 Aan: routing-wg@ripe.net Onderwerp: [routing-wg] FW: discussion about rogue database objects -----Original Message----- From: routing-wg-bounces@ripe.net [mailto:routing-wg-bounces@ripe.net] On Behalf Of Ronald F. Guilmette Sent: Monday, November 10, 2014 1:56 AM To: routing-wg@ripe.net Subject: Re: [routing-wg] discussion about rogue database objects In message <545FDE27.7030702@velea.eu>, Elvis Daniel Velea <elvis@velea.eu> wrote:

*Regarding the future process:** * I do not think it will be that easy to come up with a process. RPKI may

not be available for legacy (or independent) resources in all the regions. I think this means the RIRs will first need to speed up the deployment of RPKI for all the resources in their registries... ...

Can anyone speak to this? What resources in what registries cannot currently be covered by RPKI? If the answer is "none", then there is no problem with requiring that right now, correct? ---------------- There are actually not only technical matters, but sort to say political, law, ... As about what resources currently can't be covered by RPKI - they had already been mentioned: legacy as an example. Regards, Vladislav

Hello, I'm not sure the problem is imminent first hand. I'm sure that the routing is not RIPE NCC's business. I believe that the routing object should be created at the place where it can be checked properly. And I insist that I must NOT be forced to use the damn RPKI. Regards, Vladislav -----Original Message----- From: Gert Doering [mailto:gert@space.net] Sent: Tuesday, November 11, 2014 12:53 PM To: Potapov Vladislav Cc: routing-wg@ripe.net Subject: Re: [routing-wg] FW: discussion about rogue database objects Hi, On Tue, Nov 11, 2014 at 01:48:31PM +0400, poty@iiat.ru wrote:

Technical possibility does not mean that you can force it to be implemented. While there are related documents for legacy resources for example, not all the legacy resource holders not having any relationship with RIPE NCC will abide the rules. On the other hand not all RIPE NCC members seem to interested in RPKI as there is always a question on trusting, treats and local law. Personally me is against using this mechanism.

So, what are *your* suggestions to solve the imminent problem at hand? The requirements are clear: - permit documentation of legitimate use of out-of-region resources - stop people from adding route: objects for which they are not authorized Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hello, ---- On Wed, Nov 12, 2014 at 11:18:25AM +0400, poty@iiat.ru wrote:

I'm not sure the problem is imminent first hand.

The problem is real, and needs to be fixed. ---- Your word against my word - nothing changed in the world. ----

I'm sure that the routing is not RIPE NCC's business.

As long as nobody else is providing a high-quality and well-authenticated IRR DB for RIPE region objects, it *very much* is the RIPE NCC's business. ---- It's not me who mentioned "region". As soon as the authority of RIPE NCC is limited to RIPE region it is none of the RIPE NCC business to rule "around the world". I'm in doubt that the burden of inter-RIR arguments should be put on the end users. RPKI, when it was initially introduced, was, is and I hope will be independent decision of the end-user. ----

I believe that the routing object should be created at the place where

it can be checked properly.

Please provide suggestions how that will help RIPE region LIRs properly document their routing policy if out-of-region networks are involved. ---- The "routing policy" should be built in each region by their respective rules. If someone (including RIPE NCC) does not like the rules outside the region there should be some agreements between RIRs, not between end users. I hope you've heard my suggestion to form the routing policy in the RIR's database where it can be authenticated internally (against ASs and IP address blocks), than between complicated inter-RIR transfers. In that way it is only the inter-RIR process of exchanging high-integrity databases, not multi-thousand companies activity for implementing untrusted mechanisms to be in place. In my opinion there has been enough money spent on this already. Regards, Vladislav