2018-06 New Policy Proposal (RIPE NCC IRR Database Non-Authoritative Route Object Clean-up)
Dear colleagues, A new RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", is now available for discussion. The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-06 As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposers. At the end of the Discussion Phase, the proposers, with the agreement of the Working Group Chairs, decides how to proceed with the proposal. We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 9 November 2018. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
In message <E1gAaoe-0004fx-GZ@www-apps-1.ripe.net>, Marco Schmidt <mschmidt@ripe.net> wrote:
Two comments: 1) In section 2.0 please change the word "must" to "will". 2) Please append the following additional sentence to section 2.0: A permanent record of all route objects deleted from the RIPE IRR as a result of this policy, together with copies of all then-current referenced database objects, at the time of the deletion will be maintained and published by RIPE NCC, either via a simple plain text web page or as plain text provided to the public via some other means (e.g. a traditional port 43 WHOIS service), (I believe that all details relating to this clean-up should be preserved for posterity and should be easily accessible to both current and future researchers and historians.)
Dear Ronald, On Thu, Oct 11, 2018 at 12:41:09PM -0700, Ronald F. Guilmette wrote:
In message <E1gAaoe-0004fx-GZ@www-apps-1.ripe.net>, Marco Schmidt <mschmidt@ripe.net> wrote:
2) Please append the following additional sentence to section 2.0:
A permanent record of all route objects deleted from the RIPE IRR as a result of this policy, together with copies of all then-current referenced database objects, at the time of the deletion will be maintained and published by RIPE NCC, either via a simple plain text web page or as plain text provided to the public via some other means (e.g. a traditional port 43 WHOIS service),
(I believe that all details relating to this clean-up should be preserved for posterity and should be easily accessible to both current and future researchers and historians.)
In any case I recommend you download a copy of https://ftp.ripe.net/ripe/dbase/ripe-nonauth.db.gz which contains all the RIPE-NONAUTH data. Data can only be modified or deleted, no new data can be added to the RIPE-NONAUTH dataset. I'd personally don't really see a need to task the RIPE NCC to preserve this data forever, but I'm curious to know what others think. Kind regards, Job
* Marco Schmidt
A new RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", is now available for discussion.
The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
I've read the policy proposal and I think it makes sense. I see some respondents in db-wg asking for a notification of an upcoming deletion followed by a grace period. That's a reasonable ask, considering that a deletion of a RIPE-NONAUTH object is irreversible. In any case, +1. Tore
Im happy with the proposal, again I think the prior notification + graceperiod suggestion makes sense +1 Thanks TOm Smyth On Tue, 16 Oct 2018 at 12:57, Tore Anderson <tore@fud.no> wrote:
* Marco Schmidt
A new RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", is now available for discussion.
The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
I've read the policy proposal and I think it makes sense.
I see some respondents in db-wg asking for a notification of an upcoming deletion followed by a grace period. That's a reasonable ask, considering that a deletion of a RIPE-NONAUTH object is irreversible.
In any case, +1.
Tore
Dear Tom, Tore, On Tue, Oct 16, 2018 at 2:04 PM Tom Smyth <tom.smyth@wirelessconnect.eu> wrote:
Im happy with the proposal, again I think the prior notification + graceperiod suggestion makes sense
+1
On Tue, 16 Oct 2018 at 12:57, Tore Anderson <tore@fud.no> wrote:
* Marco Schmidt
A new RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", is now available for discussion.
The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
I've read the policy proposal and I think it makes sense.
I see some respondents in db-wg asking for a notification of an upcoming deletion followed by a grace period. That's a reasonable ask, considering that a deletion of a RIPE-NONAUTH object is irreversible.
In any case, +1.
I am not sure that RIPE NCC can reliably figure out who to email - do you email the adversary? It may be tricky to programmatically find the appropriate contacts to send the notification. The route/route6 object's "notify:" attribute (when present) is perhaps not entirely suitable in this context - since that mail address may not point to the resource holder but rather to a previous owner, an adversary or simply the wrong people. If it is acceptable to the community that a percentage of notifications won't arrive at all, or go to the entirely wrong people - I'm willing to entertain the possibility of amending the proposal to add one-off notifications when an object is deleted. But I do think it'll lead to more confusion, rather than be useful. Kind regards, Job
* Job Snijders
I am not sure that RIPE NCC can reliably figure out who to email - do you email the adversary?
It may be tricky to programmatically find the appropriate contacts to send the notification. The route/route6 object's "notify:" attribute (when present) is perhaps not entirely suitable in this context - since that mail address may not point to the resource holder but rather to a previous owner, an adversary or simply the wrong people.
If it is acceptable to the community that a percentage of notifications won't arrive at all, or go to the entirely wrong people - I'm willing to entertain the possibility of amending the proposal to add one-off notifications when an object is deleted. But I do think it'll lead to more confusion, rather than be useful.
Yes, any e-mail address associated with the object to be deleted (notify:, mnt-by:, etc). The recipient will in some cases be «the adversary», true, but I don't see the a problem with that since he will be powerless to stop the impending deletion anyway. Also, it's also acceptable if the notifications don't reach anyone at all. At least the attempt was made, we can't do much more than that. That said, this grace period is not a deal-breaker for me. I'm fine with the proposal either way, really. Tore
Hi, apologies for the top posting. I think Job’s proposal is a good one. I support it. Whether we delete the object in RIPE-NONAUTH IRR once a ROA is created or whether we delete all of them all together in one cleanup, I think we should get rid of this old stale data. I am not sure a grace period makes sense if the proposal moves forward as is. A grace period would make sense if this proposal is updated so that RIPE NCC is tasked to do a one-time cleaning of all the RIPE-NONAUTH route objects. my 2 cents, elvis Excuse the briefness of this mail, it was sent from a mobile device.
On Oct 16, 2018, at 14:18, Tore Anderson <tore@fud.no> wrote:
* Job Snijders
I am not sure that RIPE NCC can reliably figure out who to email - do you email the adversary?
It may be tricky to programmatically find the appropriate contacts to send the notification. The route/route6 object's "notify:" attribute (when present) is perhaps not entirely suitable in this context - since that mail address may not point to the resource holder but rather to a previous owner, an adversary or simply the wrong people.
If it is acceptable to the community that a percentage of notifications won't arrive at all, or go to the entirely wrong people - I'm willing to entertain the possibility of amending the proposal to add one-off notifications when an object is deleted. But I do think it'll lead to more confusion, rather than be useful.
Yes, any e-mail address associated with the object to be deleted (notify:, mnt-by:, etc).
The recipient will in some cases be «the adversary», true, but I don't see the a problem with that since he will be powerless to stop the impending deletion anyway.
Also, it's also acceptable if the notifications don't reach anyone at all. At least the attempt was made, we can't do much more than that.
That said, this grace period is not a deal-breaker for me. I'm fine with the proposal either way, really.
Tore
Hi Job, Tore I understand but there were legitimate users, of the RIPE-NONAUTH objects (those in reciept of Legacy address space) and it would serve as full and final reminder to those who legitimately used the legacy RIPE-NONAUTH objects, to get the resource holders to update / create new route objects that are authenticated and in line with best current practice. I think the risk of emailing an adversary is minimal when they cannot do much about the pending object deletion. Thanks On Tue, 16 Oct 2018 at 13:07, Job Snijders <job@instituut.net> wrote:
Dear Tom, Tore,
On Tue, Oct 16, 2018 at 2:04 PM Tom Smyth <tom.smyth@wirelessconnect.eu> wrote:
Im happy with the proposal, again I think the prior notification + graceperiod suggestion makes sense
+1
On Tue, 16 Oct 2018 at 12:57, Tore Anderson <tore@fud.no> wrote:
* Marco Schmidt
A new RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", is now available for discussion.
The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
I've read the policy proposal and I think it makes sense.
I see some respondents in db-wg asking for a notification of an upcoming deletion followed by a grace period. That's a reasonable ask, considering that a deletion of a RIPE-NONAUTH object is irreversible.
In any case, +1.
I am not sure that RIPE NCC can reliably figure out who to email - do you email the adversary?
It may be tricky to programmatically find the appropriate contacts to send the notification. The route/route6 object's "notify:" attribute (when present) is perhaps not entirely suitable in this context - since that mail address may not point to the resource holder but rather to a previous owner, an adversary or simply the wrong people.
If it is acceptable to the community that a percentage of notifications won't arrive at all, or go to the entirely wrong people - I'm willing to entertain the possibility of amending the proposal to add one-off notifications when an object is deleted. But I do think it'll lead to more confusion, rather than be useful.
Kind regards,
Job
-- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Hi Tom, On Tue, Oct 16, 2018 at 2:35 PM Tom Smyth <tom.smyth@wirelessconnect.eu> wrote:
I understand but there were legitimate users, of the RIPE-NONAUTH objects (those in reciept of Legacy address space) and it would serve as full and final reminder to those who legitimately used the legacy RIPE-NONAUTH objects, to get the resource holders to update / create new route objects that are authenticated and in line with best current practice. I think the risk of emailing an adversary is minimal when they cannot do much about the pending object deletion.
Resource holders that can create RPKI ROAs for LEGACY space can create IRR route objects in the RIPE IRR (and as such are not considered out-of-region, those objects are not in the RIPE-NONAUTH dataset). Resource holders that have legacy space anchored in the ARIN region can't create RPKI ROAs - so those objects would not be affected in any way anyhow. Kind regards, Job
Hi Job, Thanks for your email and explanation to give an example of a once legitimate user (me) in the case of 154.50.194.0/23 we were assigned from Cogent, at the time I requested support for a route object to be created, they just told us to use the generic password to add route objects in the ripe database, (AFRINIC manged legacy space) I have, since the implementation of the RIPE-NONAUTH change recently asked cogent to create routeobjects in RADB. (it should have been requested sooner by myself) so this data that was once legitimately used is still in the ripe database (and probably should have been dealt with by us already) now that it is being removed it I think a reminder to the creator of the object, that they should find an alternative would be helpful. I hope this helps clarify what I ment in relation to Legitimate users of the RIPE-NONAUTH objects Thanks Tom Smyth On Tue, 16 Oct 2018 at 13:38, Job Snijders <job@instituut.net> wrote:
Hi Tom,
On Tue, Oct 16, 2018 at 2:35 PM Tom Smyth <tom.smyth@wirelessconnect.eu> wrote:
I understand but there were legitimate users, of the RIPE-NONAUTH objects (those in reciept of Legacy address space) and it would serve as full and final reminder to those who legitimately used the legacy RIPE-NONAUTH objects, to get the resource holders to update / create new route objects that are authenticated and in line with best current practice. I think the risk of emailing an adversary is minimal when they cannot do much about the pending object deletion.
Resource holders that can create RPKI ROAs for LEGACY space can create IRR route objects in the RIPE IRR (and as such are not considered out-of-region, those objects are not in the RIPE-NONAUTH dataset).
Resource holders that have legacy space anchored in the ARIN region can't create RPKI ROAs - so those objects would not be affected in any way anyhow.
Kind regards,
Job
I think from my perspective as a staffer in another RIR, with users who are concerned about abuse of their resources in the RIPE IRR, this is a good proposal. Anyone who is able to create a signed assertion of intent has a strong-proof of intent, which should stand, if older data contradicts it. If this proposal means that the IRR will honour the signed intent, It feels like a good outcome. I am also aware of a number of BGP speakers in the APNIC region who appear to have long-held, stable state in the RIPE IRR data who may be adversely affected by removal so I am keen that the contact from RIPE happens, but its understood older objects may have stale contact info: This simply may not get all cases. Since the specifics here are that a ROA leads to removal, it requires the prime resource holder (inetnums) to consent. That feels respectful of their intent. If they have "forgotten" as a company they depend on IRR data, they are also actively engaged in routing (made the ROA) inside the correct RIR's systems, so the solution appears tractable. https://blog.apnic.net/wp-content/uploads/2018/08/Count-of-route-route6-obje... This shows the histogram of objects by age, which refer to APNIC region resources. Approximately 2,900 distinct APNIC region prefixes are represented in route: and route6: objects in the RIPE NCC database. These prefixes distribute over 385 distinct address holders, indirect (NIR sub-account) address holders, a mix of Members, and historical Non-Member resource holders. (from https://blog.apnic.net/2018/08/30/ripe-ncc-moves-to-close-off-a-routing-regi...) I don't think RIR staff should participate in the consensus call on these things, so I offer this as "information around the subject" -George On Thu, Oct 11, 2018 at 3:16 PM Marco Schmidt <mschmidt@ripe.net> wrote:
Dear colleagues,
A new RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", is now available for discussion.
The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-06
As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposers.
At the end of the Discussion Phase, the proposers, with the agreement of the Working Group Chairs, decides how to proceed with the proposal.
We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 9 November 2018.
Kind regards,
Marco Schmidt Policy Officer RIPE NCC
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
participants (8)
-
Elvis Daniel Velea -
George Michaelson -
Job Snijders -
Job Snijders -
Marco Schmidt -
Ronald F. Guilmette -
Tom Smyth -
Tore Anderson