Re: [db-wg] RIPE Policy Proposal 2018-06 Aims to Delete Conflicting Non-authorative IRR Objects
2Robert How does it help to get rid of commercial IRRs? It's only RIPE policy, it doesn't work like GPDR. :) 2Job There is only one good thing about mistakes - if you can fix it. Here if one fails to properly configure ROAs it may lead to ongoing operational problems, that can't be fixed even after fixing ROAs, since RIPE-NONAUTH database is locked. I think, that it's ok to delete route objects that conflict with ROAs only if you are able to create new. Otherwise, the only winning party will be commercial IRRs. пн, 15 окт. 2018 г. в 17:29, Alexander Azimov <aa@qrator.net>:
2Robert How does it help to get rid of commercial IRRs? It's only RIPE policy, it doesn't work like GPDR. :)
2Job There is only one good thing about mistakes - you can fix it. Here if one fails to properly configure ROAs it may lead to ongoing operational problems, that can't be fixed even after fixing ROAs, since RIPE-NONAUTH database is locked. I think, that it's ok to delete route objects that conflict with ROAs only if you are able to create new. Otherwise, the only winning party will be commercial IRRs.
пн, 15 окт. 2018 г. в 17:06, Robert Heuvel via db-wg <db-wg@ripe.net>:
Hi,
Where can we express our support for this RIPE Policy proposal? We think it is a great idea and gets rid of commercial IIRs where you can register just about anything which is or is not yours...
Robert Heuvel atom86 (AS8455)
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
-- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | visit: radar.qrator.net
-- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | visit: radar.qrator.net
On Mon, Oct 15, 2018 at 16:35 Alexander Azimov via db-wg <db-wg@ripe.net> wrote:
There is only one good thing about mistakes - if you can fix it. Here if one fails to properly configure ROAs it may lead to ongoing operational problems, that can't be fixed even after fixing ROAs, since RIPE-NONAUTH database is locked. I think, that it's ok to delete route objects that conflict with ROAs only if you are able to create new. Otherwise, the only winning party will be commercial IRRs.
Alex - just create the route object in the correct database. Why help proliferate rogue or stale route announcements? It is outside RIPE’s scope to facilitate hijacks and increased risk to one business’ operations through incorrect routing information registration. If you can’t create the route object, perhaps you aren’t authorized by the owner of the resource and have no business creating such objects. This is no different than configuring the wrong DS records at the domain registry level, or generating TLS certs for the wrong hostname, or misconfiguring your firewalls or routers. Misconfigurations lead to issues - news at 11. Kind regards, Job
Why don't delete RIPE-NONAUTH at all? If there is no legal use of it - there is no need to maintain it. If there are legal use cases - you would create unpredictable operational problems, when the customer will set up an ROA, forgetting for a moment that provider is advertising its prefix for him, then he will fix ROA - but the route object will be already gone. You have NTTCOM to register objects for your customers, some other Tier1 telcos also have similar service. The lock of RIPE-NONAUTH and this policy forces smaller ISPs to pay an additional fee to RADB. I agree with the idea to drop (freeze) 'invalids', but only if you are able to restore 'valids'. пн, 15 окт. 2018 г. в 17:43, Job Snijders <job@instituut.net>:
On Mon, Oct 15, 2018 at 16:35 Alexander Azimov via db-wg <db-wg@ripe.net> wrote:
There is only one good thing about mistakes - if you can fix it. Here if one fails to properly configure ROAs it may lead to ongoing operational problems, that can't be fixed even after fixing ROAs, since RIPE-NONAUTH database is locked. I think, that it's ok to delete route objects that conflict with ROAs only if you are able to create new. Otherwise, the only winning party will be commercial IRRs.
Alex - just create the route object in the correct database.
Why help proliferate rogue or stale route announcements? It is outside RIPE’s scope to facilitate hijacks and increased risk to one business’ operations through incorrect routing information registration.
If you can’t create the route object, perhaps you aren’t authorized by the owner of the resource and have no business creating such objects.
This is no different than configuring the wrong DS records at the domain registry level, or generating TLS certs for the wrong hostname, or misconfiguring your firewalls or routers. Misconfigurations lead to issues - news at 11.
Kind regards,
Job
-- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | visit: radar.qrator.net
Dear Alexander, On Mon, Oct 15, 2018 at 06:21:09PM +0300, Alexander Azimov wrote:
Why don't delete RIPE-NONAUTH at all?
That is fine by me - but I think this community may appreciate a softer landing. Deleting the data-set resolves a number of concerns, but I'm also happy to just clean it up using superior data sources such as RPKI.
If there is no legal use of it - there is no need to maintain it. If there are legal use cases - you would create unpredictable operational problems, when the customer will set up an ROA, forgetting for a moment that provider is advertising its prefix for him, then he will fix ROA - but the route object will be already gone.
You have NTTCOM to register objects for your customers, some other Tier1 telcos also have similar service. The lock of RIPE-NONAUTH and this policy forces smaller ISPs to pay an additional fee to RADB.
"forces smaller ISPs to pay" is absolute nonsense! Please *precisely* explain the scenario in which your statements hold true. Do RIPE, AFRINIC, APNIC and ARIN not provide a *FREE* IRR service to their stakeholders? LACNIC offers RPKI ROA services which are mirrored into the NTTCOM IRR, and they are working on doing this natively. If you are not authorised to create a route object, and thus can't create a route object - that is a feature! That is precisely why the security model exists.
I agree with the idea to drop (freeze) 'invalids', but only if you are able to restore 'valids'.
Why? RIPE NCC is chartered to serve the RIPE region - not chartered to facilitate hijacks and negative effects of misconfigurations related to resources owned by entities outside the RIPE region. If you'd like RIPE NCC to offer unvalidated 'RADB' style services, feel free to bring a proposal to the RIPE Services Working Group! Kind regards, Job
Alex - just create the route object in the correct database.
no impure genetics in the ripe database. they should live in theit own neighborhoods! randy
On Mon, Oct 15, 2018 at 18:30 Randy Bush via db-wg <db-wg@ripe.net> wrote:
Alex - just create the route object in the correct database.
no impure genetics in the ripe database. they should live in theit own neighborhoods!
I don’t understand what you intend to convene to the working group. Genetics are not part of this policy proposal. Regards, Job
Alex - just create the route object in the correct database. no impure genetics in the ripe database. they should live in theit own neighborhoods! I don’t understand what you intend to convene to the working group. Genetics are not part of this policy proposal.
maybe. but segregation and our data are superior to yours by birth seems to be. some of us live on the global internet. we use all the irrs because that's reality. from the ops pov, trump has not yet made the 1-bits gold in one rir. we have a path to significantly higher quality data to verify routing data. can we focus on that, and not the purification of the irr race? randy
participants (3)
-
Alexander Azimov -
Job Snijders -
Randy Bush