NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request
DB-WG Members, Support was shown for the proposal NWI-5 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-5 as described. This request is to remove “origin:” and flag “route:” objects as specified. The db-wg therefore ask the RIPE NCC to prepare an impact analysis, followed by an implementation plan and timeline for this request and the other issues raised in the problem solution of NWI-5 as follows: 1) Remove the "origin:" authorization requirement. 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data. Thank you all for your work on this proposal! Kind regards, William & Denis DB-WG co-chairs
Dear working group, We are tasked by the co-chairs on 19 October 2017 to come up with an implementation proposal for NWI-5. It was suggested that the proposal should follow the suggestions done in the problem definition phase and focus on: 1) Remove the "origin:" authorization requirement 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data. We suggest the following solution as a basis for further discussion. 1) Remove the "origin:" authorization requirement ROUTE(6) Objects can be created as authorised by matching or overlapping INET(6)NUM, or ROUTE(6) objects, but authorisation by the AUT-NUM in the “origin:” attribute is no longer required. This means these objects will be created immediately, and the ‘pending object creation’ that is currently in place can be removed. This will allow us to simplify the core whois code as well as provide users with an easier user interface to manage their ROUTE(6) objects and compare these objects to the actual announcements done in BGP - similar to the interface currently provided to manage ROAs. Furthermore, the "mnt-routes:" attribute on AUT-NUM objects will no longer be useful. We propose that the attribute is deprecated and removed from existing objects (of course with notification to the object holders). Finally, there will be no more need for the existence of out-of-region AUT-NUM objects in the RIPE database. We propose that these objects will be deleted. 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data. ROUTE(6) Objects referring to a prefix in RIPE managed space will retain "source: RIPE”. ROUTE(6) Objects referring to a prefix outside of RIPE managed space will be moved out of the RIPE Database into a new source hosted by RIPE NCC, and will have "source: RIPE-NONAUTH”. In case of inter-RIR transfers of live networks, ROUTE(6) objects are sometimes preserved for the transferred prefix(es). If so, they will be moved between the ‘RIPE’ and ‘RIPE-NONAUTH’ sections according to the direction of the transfer. If ‘--sources' is used in queries out-of-region resources will be shown only if ‘RIPE-NONAUTH’ is included explicitly. If no source is defined we propose that both "source: RIPE" and “source: RIPE-NONAUTH” ROUTE(6) objects are returned. We expect that otherwise existing scripts used to generate filter lists will no longer see the out-of-region ROUTE(6) objects, and that this will lead to unacceptably large number of issues. Operators can opt-in to discarding objects that use “source: RIPE-NONAUTH” in these scripts, or modify them to use “--sources RIPE” explicitly. From our point of view these changes are not hard to implement on the core whois software, and removing the “origin:” authorisation requirement in particular will allow us to simplify things which will improve maintainability and allow for an easier user interface. That said, we know that there have been different opinions on the feasibility of this in the past, so we encourage the working group to discuss this. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technical Officer RIPE NCC
On 19 Oct 2017, at 17:40, William Sylvester via db-wg <db-wg@ripe.net> wrote:
DB-WG Members,
Support was shown for the proposal NWI-5 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-5 as described.
This request is to remove “origin:” and flag “route:” objects as specified. The db-wg therefore ask the RIPE NCC to prepare an impact analysis, followed by an implementation plan and timeline for this request and the other issues raised in the problem solution of NWI-5 as follows:
1) Remove the "origin:" authorization requirement.
2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.
Thank you all for your work on this proposal!
Kind regards,
William & Denis DB-WG co-chairs
Deqr all, RIPE NCC's understanding of the requested solution is in agreement with my own understanding. The NCC has identified the requested changes as a simplification which is always good news. The suggestion to deprecate "mnt-routes:" is a good one, and should be followed. Based on RIPE NCC's report, I support moving this NWI to the next phase (implementation). Kind regards, Job ps. I'd leave the 'clean up out-of-region AUT-NUMs' for a separate discussion on how to handle that data. Combining datamodel changes and governance of existing data in the same topic might distract. On Tue, Dec 05, 2017 at 10:11:43AM +0100, Tim Bruijnzeels via db-wg wrote:
Dear working group,
We are tasked by the co-chairs on 19 October 2017 to come up with an implementation proposal for NWI-5. It was suggested that the proposal should follow the suggestions done in the problem definition phase and focus on: 1) Remove the "origin:" authorization requirement 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.
We suggest the following solution as a basis for further discussion.
1) Remove the "origin:" authorization requirement
ROUTE(6) Objects can be created as authorised by matching or overlapping INET(6)NUM, or ROUTE(6) objects, but authorisation by the AUT-NUM in the “origin:” attribute is no longer required. This means these objects will be created immediately, and the ‘pending object creation’ that is currently in place can be removed. This will allow us to simplify the core whois code as well as provide users with an easier user interface to manage their ROUTE(6) objects and compare these objects to the actual announcements done in BGP - similar to the interface currently provided to manage ROAs.
Furthermore, the "mnt-routes:" attribute on AUT-NUM objects will no longer be useful. We propose that the attribute is deprecated and removed from existing objects (of course with notification to the object holders). Finally, there will be no more need for the existence of out-of-region AUT-NUM objects in the RIPE database. We propose that these objects will be deleted.
2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.
ROUTE(6) Objects referring to a prefix in RIPE managed space will retain "source: RIPE”. ROUTE(6) Objects referring to a prefix outside of RIPE managed space will be moved out of the RIPE Database into a new source hosted by RIPE NCC, and will have "source: RIPE-NONAUTH”.
In case of inter-RIR transfers of live networks, ROUTE(6) objects are sometimes preserved for the transferred prefix(es). If so, they will be moved between the ‘RIPE’ and ‘RIPE-NONAUTH’ sections according to the direction of the transfer.
If ‘--sources' is used in queries out-of-region resources will be shown only if ‘RIPE-NONAUTH’ is included explicitly. If no source is defined we propose that both "source: RIPE" and “source: RIPE-NONAUTH” ROUTE(6) objects are returned. We expect that otherwise existing scripts used to generate filter lists will no longer see the out-of-region ROUTE(6) objects, and that this will lead to unacceptably large number of issues. Operators can opt-in to discarding objects that use “source: RIPE-NONAUTH” in these scripts, or modify them to use “--sources RIPE” explicitly.
From our point of view these changes are not hard to implement on the core whois software, and removing the “origin:” authorisation requirement in particular will allow us to simplify things which will improve maintainability and allow for an easier user interface. That said, we know that there have been different opinions on the feasibility of this in the past, so we encourage the working group to discuss this.
Kind regards
Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technical Officer RIPE NCC
On 19 Oct 2017, at 17:40, William Sylvester via db-wg <db-wg@ripe.net> wrote:
DB-WG Members,
Support was shown for the proposal NWI-5 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-5 as described.
This request is to remove “origin:” and flag “route:” objects as specified. The db-wg therefore ask the RIPE NCC to prepare an impact analysis, followed by an implementation plan and timeline for this request and the other issues raised in the problem solution of NWI-5 as follows:
1) Remove the "origin:" authorization requirement.
2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.
Thank you all for your work on this proposal!
Kind regards,
William & Denis DB-WG co-chairs
Hi Job,
On 5 Dec 2017, at 11:07, Job Snijders <job@ntt.net> wrote:
ps. I'd leave the 'clean up out-of-region AUT-NUMs' for a separate discussion on how to handle that data. Combining datamodel changes and governance of existing data in the same topic might distract.
This can be a separate effort. However, what I did not mention earlier is that we probably should disallow the creation of new out-of-region AUT-NUM objects if they are no longer required to authorise ROUTE(6) objects. Kind regards, Tim
On Tue, Dec 05, 2017 at 12:04:59PM +0100, Tim Bruijnzeels wrote:
On 5 Dec 2017, at 11:07, Job Snijders <job@ntt.net> wrote:
ps. I'd leave the 'clean up out-of-region AUT-NUMs' for a separate discussion on how to handle that data. Combining datamodel changes and governance of existing data in the same topic might distract.
This can be a separate effort. However, what I did not mention earlier is that we probably should disallow the creation of new out-of-region AUT-NUM objects if they are no longer required to authorise ROUTE(6) objects.
Yes, I support disallowing the creation of NEW out-of-region AUT-NUM and ROUTE objects. I keep seeing route objects covering non-RIPE IP space popping up in the RIPE IRR for nefarious purposes. An ideal outcome is that the RIPE IRR contains only RIPE NCC managed resources. A first step towards that goal is to stop accepting new "RIPE-NONAUTH" objects. Kind regards, Job
This can be a separate effort. However, what I did not mention earlier is that we probably should disallow the creation of new out-of-region AUT-NUM objects if they are no longer required to authorise ROUTE(6) objects.
how long do you think it will be before there are no inter-region barriers to AS transfers? add a year or so to that to give people time to clean up the mess caused by this policy hole.
Yes, I support disallowing the creation of NEW out-of-region AUT-NUM and ROUTE objects.
not exact;ly what tim was suggesting, see above.
I keep seeing route objects covering non-RIPE IP space popping up in the RIPE IRR for nefarious purposes.
that may be the wrong question. are some appearing for legitimate and useful purposes? if so, how will those needs be addressed going forward? randy
My personal (and I stress personal) opinion moving forward, is that the use of an IRR really does not sit well with the management side of delegation of authority in a distributed model that we have right now. If we move to a model where the IRR/RPSL "maintainer" is understood to be documentation and not the actual authority over change, we can discuss more rational mechanisms to certify (and I use that word deliberately) that a given person has shown their intent, and consent, to have a given IRR/RPSL statement made over their resources. If we did that, then any delegated authority over some INR should be able to make statements which validate the insertion into any IRR. The problem of course (wilfred: hello) is referential integrity. Which I cannot fix because this is a fundamental problem in distributed systems which have hierarchy of independent elements capable of withdrawing consent. I suspect the fix is to put maximum lifetime on things being retained without reference to an explicit permission granted from outside and then remove them. I don't configure routers. I therefore can't meaningfully comment on the costs on the configuration side, of this. -George On Wed, Feb 14, 2018 at 1:59 PM, Randy Bush via db-wg <db-wg@ripe.net> wrote:
This can be a separate effort. However, what I did not mention earlier is that we probably should disallow the creation of new out-of-region AUT-NUM objects if they are no longer required to authorise ROUTE(6) objects.
how long do you think it will be before there are no inter-region barriers to AS transfers? add a year or so to that to give people time to clean up the mess caused by this policy hole.
Yes, I support disallowing the creation of NEW out-of-region AUT-NUM and ROUTE objects.
not exact;ly what tim was suggesting, see above.
I keep seeing route objects covering non-RIPE IP space popping up in the RIPE IRR for nefarious purposes.
that may be the wrong question. are some appearing for legitimate and useful purposes? if so, how will those needs be addressed going forward?
randy
My personal (and I stress personal) opinion moving forward, is that the use of an IRR really does not sit well with the management side of delegation of authority in a distributed model that we have right now.
If we move to a model where the IRR/RPSL "maintainer" is understood to be documentation and not the actual authority over change, we can discuss more rational mechanisms to certify (and I use that word deliberately) that a given person has shown their intent, and consent, to have a given IRR/RPSL statement made over their resources.
If we did that, then any delegated authority over some INR should be able to make statements which validate the insertion into any IRR.
The problem of course (wilfred: hello) is referential integrity. Which I cannot fix because this is a fundamental problem in distributed systems which have hierarchy of independent elements capable of withdrawing consent. I suspect the fix is to put maximum lifetime on things being retained without reference to an explicit permission granted from outside and then remove them.
I don't configure routers. I therefore can't meaningfully comment on the costs on the configuration side, of this.
not positive i get your intent here. but seems a lot as if you are hoping to apply an external formally defined authorisation structure to add artistic verisimilitude to an otherwise bald and unconvincing narrative, the irr. it is amusing to watch, after decades of failure on intra-irr authentication and authorisation, we are now going to a new fantasy where we restrict a registry to 'our' data; when the quality of the various rirs' data are mediocre at best. mr trump, the problem isn't nasty 'foreign' irr data raping our route6: objects. the problem is all irr data. folk are trying to whitewash quality and security decades ex post facto; a well known joke. what we need is a formally verifyable hierarchy whch matches the actual delegations, iana on down. oh, wait... randy
On Wed, Feb 14, 2018 at 12:59:22PM +0900, Randy Bush via db-wg wrote:
This can be a separate effort. However, what I did not mention earlier is that we probably should disallow the creation of new out-of-region AUT-NUM objects if they are no longer required to authorise ROUTE(6) objects.
how long do you think it will be before there are no inter-region barriers to AS transfers? add a year or so to that to give people time to clean up the mess caused by this policy hole.
It is not entirely clear to me what the issue of inter-RIR ASN transfers has to do with the topic at hand. However, there is a lively discussion on ARIN PPML about Inter-RIR ASN transfers, you too can participate: http://lists.arin.net/pipermail/arin-ppml/2018-February/thread.html
Yes, I support disallowing the creation of NEW out-of-region AUT-NUM and ROUTE objects.
not exact;ly what tim was suggesting, see above.
I keep seeing route objects covering non-RIPE IP space popping up in the RIPE IRR for nefarious purposes.
that may be the wrong question. are some appearing for legitimate and useful purposes? if so, how will those needs be addressed going forward?
I'm happy to discuss "legitimate use cases", provided they exist, and aren't the result of an incorrect use of the RIPE IRR. Can you share some? To me it is quite significant that I'm not aware of operational issues related to the policies of the APNIC IRR, and RIPE is moving towards that same model. Kind regards, Job
This can be a separate effort. However, what I did not mention earlier is that we probably should disallow the creation of new out-of-region AUT-NUM objects if they are no longer required to authorise ROUTE(6) objects.
how long do you think it will be before there are no inter-region barriers to AS transfers? add a year or so to that to give people time to clean up the mess caused by this policy hole.
It is not entirely clear to me what the issue of inter-RIR ASN transfers has to do with the topic at hand. However, there is a lively discussion on ARIN PPML about Inter-RIR ASN transfers, you too can participate: http://lists.arin.net/pipermail/arin-ppml/2018-February/thread.html
there is a lively bunch of animals in that pile of chicken manure over in the barnyard; you too can participate. i'll count my chickens when they hatch. in the meantime, i have ARIN ASs announcing RIPE prefixes, as do many others. randy
Tim Bruijnzeels via db-wg wrote:
Dear working group,
We are tasked by the co-chairs on 19 October 2017 to come up with an implementation proposal for NWI-5.
This looks sensible overall and I'd like to see this moving forward. Couple of things:
object holders). Finally, there will be no more need for the existence of out-of-region AUT-NUM objects in the RIPE database. We propose that these objects will be deleted.
I would prefer this in the longer term, but some people may have difficulties if they depend on these objects being in the ripe database. The same set of issues applies to aut-num objects as to route/route6 objects, so probably the same solution should be applied, i.e. mark them all with source: RIPE-NONAUTH and let them remain there.
2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.
yes, finally!
If ‘--sources' is used in queries out-of-region resources will be shown only if ‘RIPE-NONAUTH’ is included explicitly. If no source is defined we propose that both "source: RIPE" and “source: RIPE-NONAUTH” ROUTE(6) objects are returned. We expect that otherwise existing scripts used to generate filter lists will no longer see the out-of-region ROUTE(6) objects, and that this will lead to unacceptably large number of issues. Operators can opt-in to discarding objects that use “source: RIPE-NONAUTH” in these scripts, or modify them to use “--sources RIPE” explicitly.
this looks sensible. One final issue that hasn't been addressed: should it be possible for new objects to be created with source: RIPE-NONAUTH? My preference would be not, but this is something that we might want to discuss in the working group. Nick
I concur with this. And, I think that probably you are right Tim, and out-of-region data should be disallowed, if not needed. I'd also ask for documentation associated with RPSL and route object and aut-num management to be reviewed and updated to reflect the emerging reality. -George On Wed, Dec 13, 2017 at 8:16 AM, Nick Hilliard via db-wg <db-wg@ripe.net> wrote:
Tim Bruijnzeels via db-wg wrote:
Dear working group,
We are tasked by the co-chairs on 19 October 2017 to come up with an implementation proposal for NWI-5.
This looks sensible overall and I'd like to see this moving forward. Couple of things:
object holders). Finally, there will be no more need for the existence of out-of-region AUT-NUM objects in the RIPE database. We propose that these objects will be deleted.
I would prefer this in the longer term, but some people may have difficulties if they depend on these objects being in the ripe database. The same set of issues applies to aut-num objects as to route/route6 objects, so probably the same solution should be applied, i.e. mark them all with source: RIPE-NONAUTH and let them remain there.
2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.
yes, finally!
If ‘--sources' is used in queries out-of-region resources will be shown only if ‘RIPE-NONAUTH’ is included explicitly. If no source is defined we propose that both "source: RIPE" and “source: RIPE-NONAUTH” ROUTE(6) objects are returned. We expect that otherwise existing scripts used to generate filter lists will no longer see the out-of-region ROUTE(6) objects, and that this will lead to unacceptably large number of issues. Operators can opt-in to discarding objects that use “source: RIPE-NONAUTH” in these scripts, or modify them to use “--sources RIPE” explicitly.
this looks sensible.
One final issue that hasn't been addressed: should it be possible for new objects to be created with source: RIPE-NONAUTH? My preference would be not, but this is something that we might want to discuss in the working group.
Nick
Hi all From: Nick Hilliard via db-wg <db-wg@ripe.net> To: Tim Bruijnzeels <tim@ripe.net> Cc: Database WG <db-wg@ripe.net> Sent: Tuesday, 12 December 2017, 23:16 Subject: Re: [db-wg] NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request Tim Bruijnzeels via db-wg wrote:
Dear working group,
We are tasked by the co-chairs on 19 October 2017 to come up with an implementation proposal for NWI-5.
One final issue that hasn't been addressed: should it be possible for new objects to be created with source: RIPE-NONAUTH? My preference would be not, but this is something that we might want to discuss in the working group. Before answering this question, perhaps Tim you can say if it will still be possible to create foreign ROUTE objects after this implementation? Currently there are place holder INET(6)NUM objects in the RIPE Database covering all non RIPE address space. These objects have an "mnt-routes:" attribute referencing the MNTNER object with the public password. This is necessary to (by)pass the address space auth requirements for creating ROUTE(6) objects. Do you plan to make any changes to this mechanism/arrangement with this implementation? cheersdenisco-chair DB WG
Nick
Hi all,
On 13 Dec 2017, at 19:25, denis walker <ripedenis@yahoo.co.uk> wrote:
Hi all
From: Nick Hilliard via db-wg <db-wg@ripe.net> To: Tim Bruijnzeels <tim@ripe.net> Cc: Database WG <db-wg@ripe.net> Sent: Tuesday, 12 December 2017, 23:16 Subject: Re: [db-wg] NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request
Tim Bruijnzeels via db-wg wrote:
Dear working group,
We are tasked by the co-chairs on 19 October 2017 to come up with an implementation proposal for NWI-5.
One final issue that hasn't been addressed: should it be possible for new objects to be created with source: RIPE-NONAUTH? My preference would be not, but this is something that we might want to discuss in the working group.
Before answering this question, perhaps Tim you can say if it will still be possible to create foreign ROUTE objects after this implementation?
The proposal I wrote was scoped to the following only, as per request of the co-chairs: 1) Remove the "origin:" authorization requirement 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data. So, in my mind this will still allow the creation of new ROUTE(6) objects with “source: RIPE-NONAUTH”. I am not opposed to disallowing this, and only allow existing objects to be modified or deleted. We get a lot of complaints about out-of-region objects - and we don’t have a clear mandate to do anything with these objects. Preventing the creation of additional objects will at least prevent this situation from getting worse. It would also be a strong indication that such objects should be created in the authoritative databases as far as they exist, especially the APNIC and AFRINIC databases. For ARIN and LACNIC space this may not be possible though: I believe that ARIN has plans to work on their IRR, but for the moment RADB would then be the de-facto place. LACNIC does not currently support ROUTE(6) objects, but does have good RPKI data that one could use: https://lirportal.ripe.net/certification/content/static/statistics/world-roa... But, as RIPE NCC staff, I believe the working group should discuss this and my opinion on this is secondary.
Currently there are place holder INET(6)NUM objects in the RIPE Database covering all non RIPE address space. These objects have an "mnt-routes:" attribute referencing the MNTNER object with the public password. This is necessary to (by)pass the address space auth requirements for creating ROUTE(6) objects. Do you plan to make any changes to this mechanism/arrangement with this implementation?
If no more new RIPE-NONAUTH ROUTE(6) objects may be created then the “mnt-routes:” attribute on these placeholders should be removed. Kind regards Tim
cheers denis co-chair DB WG
Nick
On Thu, Dec 14, 2017 at 9:55 AM, Tim Bruijnzeels via db-wg <db-wg@ripe.net> wrote:
But, as RIPE NCC staff, I believe the working group should discuss this and my opinion on this is secondary.
Disagree. RIPE NCC is the focus point of input from all the community (vs. the dozen ppl who are active on this list). There is a lot more going on in direct emails/tickets/phone calls than one sees here. Input and opinion from NCC staff is just as important as any other community member's. As for the proposal, basically any cleanup in the area is much needed. Current situation is anything but obvious or useful. Agoston
On 05/12/2017, 11:11, Tim Bruijnzeels via db-wg typed:
We suggest the following solution as a basis for further discussion.
1) Remove the "origin:" authorization requirement
the "mnt-routes:" attribute on AUT-NUM objects will no longer be useful. We propose that the attribute is deprecated and removed from existing objects (of course with notification to the object holders).
Finally, there will be no more need for the existence of out-of-region AUT-NUM objects in the RIPE database. We propose that these objects will be deleted.
2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.
This all looks good to me. I'm in agreement as is. Thanks, Daniel
I agree with this approach. Aside from all the immediate benefits it will clear the path for a clean approach to aligning route object and RPKI ROA management. Kind regards, Alex
On 5 Dec 2017, at 10:11, Tim Bruijnzeels via db-wg <db-wg@ripe.net> wrote:
Dear working group,
We are tasked by the co-chairs on 19 October 2017 to come up with an implementation proposal for NWI-5. It was suggested that the proposal should follow the suggestions done in the problem definition phase and focus on: 1) Remove the "origin:" authorization requirement 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.
We suggest the following solution as a basis for further discussion.
1) Remove the "origin:" authorization requirement
ROUTE(6) Objects can be created as authorised by matching or overlapping INET(6)NUM, or ROUTE(6) objects, but authorisation by the AUT-NUM in the “origin:” attribute is no longer required. This means these objects will be created immediately, and the ‘pending object creation’ that is currently in place can be removed. This will allow us to simplify the core whois code as well as provide users with an easier user interface to manage their ROUTE(6) objects and compare these objects to the actual announcements done in BGP - similar to the interface currently provided to manage ROAs.
Furthermore, the "mnt-routes:" attribute on AUT-NUM objects will no longer be useful. We propose that the attribute is deprecated and removed from existing objects (of course with notification to the object holders). Finally, there will be no more need for the existence of out-of-region AUT-NUM objects in the RIPE database. We propose that these objects will be deleted.
2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.
ROUTE(6) Objects referring to a prefix in RIPE managed space will retain "source: RIPE”. ROUTE(6) Objects referring to a prefix outside of RIPE managed space will be moved out of the RIPE Database into a new source hosted by RIPE NCC, and will have "source: RIPE-NONAUTH”.
In case of inter-RIR transfers of live networks, ROUTE(6) objects are sometimes preserved for the transferred prefix(es). If so, they will be moved between the ‘RIPE’ and ‘RIPE-NONAUTH’ sections according to the direction of the transfer.
If ‘--sources' is used in queries out-of-region resources will be shown only if ‘RIPE-NONAUTH’ is included explicitly. If no source is defined we propose that both "source: RIPE" and “source: RIPE-NONAUTH” ROUTE(6) objects are returned. We expect that otherwise existing scripts used to generate filter lists will no longer see the out-of-region ROUTE(6) objects, and that this will lead to unacceptably large number of issues. Operators can opt-in to discarding objects that use “source: RIPE-NONAUTH” in these scripts, or modify them to use “--sources RIPE” explicitly.
From our point of view these changes are not hard to implement on the core whois software, and removing the “origin:” authorisation requirement in particular will allow us to simplify things which will improve maintainability and allow for an easier user interface. That said, we know that there have been different opinions on the feasibility of this in the past, so we encourage the working group to discuss this.
Kind regards
Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technical Officer RIPE NCC
On 19 Oct 2017, at 17:40, William Sylvester via db-wg <db-wg@ripe.net> wrote:
DB-WG Members,
Support was shown for the proposal NWI-5 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-5 as described.
This request is to remove “origin:” and flag “route:” objects as specified. The db-wg therefore ask the RIPE NCC to prepare an impact analysis, followed by an implementation plan and timeline for this request and the other issues raised in the problem solution of NWI-5 as follows:
1) Remove the "origin:" authorization requirement.
2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.
Thank you all for your work on this proposal!
Kind regards,
William & Denis DB-WG co-chairs
Hi Tim I just noticed the comment below:"In case of inter-RIR transfers of live networks, ROUTE(6) objects are sometimes preserved for the transferred prefix(es). If so, they will be moved between the ‘RIPE’ and ‘RIPE-NONAUTH’ sections according to the direction of the transfer." Does this mean if a prefix is transferred into the RIPE region which currently has a ROUTE(6) object with the source 'RIPE-NONAUTH' this object will be re-tagged with the source 'RIPE'? If so are we giving a label of legitimacy to an object that was not properly authenticated? cheersdenisco-chair DB WG From: Tim Bruijnzeels via db-wg <db-wg@ripe.net> To: Database WG <db-wg@ripe.net> Sent: Tuesday, 5 December 2017, 10:12 Subject: Re: [db-wg] NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request Dear working group, We are tasked by the co-chairs on 19 October 2017 to come up with an implementation proposal for NWI-5. It was suggested that the proposal should follow the suggestions done in the problem definition phase and focus on: 1) Remove the "origin:" authorization requirement 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data. We suggest the following solution as a basis for further discussion. 1) Remove the "origin:" authorization requirement ROUTE(6) Objects can be created as authorised by matching or overlapping INET(6)NUM, or ROUTE(6) objects, but authorisation by the AUT-NUM in the “origin:” attribute is no longer required. This means these objects will be created immediately, and the ‘pending object creation’ that is currently in place can be removed. This will allow us to simplify the core whois code as well as provide users with an easier user interface to manage their ROUTE(6) objects and compare these objects to the actual announcements done in BGP - similar to the interface currently provided to manage ROAs. Furthermore, the "mnt-routes:" attribute on AUT-NUM objects will no longer be useful. We propose that the attribute is deprecated and removed from existing objects (of course with notification to the object holders). Finally, there will be no more need for the existence of out-of-region AUT-NUM objects in the RIPE database. We propose that these objects will be deleted. 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data. ROUTE(6) Objects referring to a prefix in RIPE managed space will retain "source: RIPE”. ROUTE(6) Objects referring to a prefix outside of RIPE managed space will be moved out of the RIPE Database into a new source hosted by RIPE NCC, and will have "source: RIPE-NONAUTH”. In case of inter-RIR transfers of live networks, ROUTE(6) objects are sometimes preserved for the transferred prefix(es). If so, they will be moved between the ‘RIPE’ and ‘RIPE-NONAUTH’ sections according to the direction of the transfer. If ‘--sources' is used in queries out-of-region resources will be shown only if ‘RIPE-NONAUTH’ is included explicitly. If no source is defined we propose that both "source: RIPE" and “source: RIPE-NONAUTH” ROUTE(6) objects are returned. We expect that otherwise existing scripts used to generate filter lists will no longer see the out-of-region ROUTE(6) objects, and that this will lead to unacceptably large number of issues. Operators can opt-in to discarding objects that use “source: RIPE-NONAUTH” in these scripts, or modify them to use “--sources RIPE” explicitly.
From our point of view these changes are not hard to implement on the core whois software, and removing the “origin:” authorisation requirement in particular will allow us to simplify things which will improve maintainability and allow for an easier user interface. That said, we know that there have been different opinions on the feasibility of this in the past, so we encourage the working group to discuss this.
Kind regards Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technical Officer RIPE NCC
On 19 Oct 2017, at 17:40, William Sylvester via db-wg <db-wg@ripe.net> wrote:
DB-WG Members, Support was shown for the proposal NWI-5 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-5 as described. This request is to remove “origin:” and flag “route:” objects as specified. The db-wg therefore ask the RIPE NCC to prepare an impact analysis, followed by an implementation plan and timeline for this request and the other issues raised in the problem solution of NWI-5 as follows: 1) Remove the "origin:" authorization requirement. 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data. Thank you all for your work on this proposal! Kind regards, William & Denis DB-WG co-chairs
Hi Tim, Denis, On Wed, Jan 10, 2018 at 11:33:10PM +0000, denis walker via db-wg wrote:
I just noticed the comment below:"In case of inter-RIR transfers of live networks, ROUTE(6) objects are sometimes preserved for the transferred prefix(es). If so, they will be moved between the ‘RIPE’ and ‘RIPE-NONAUTH’ sections according to the direction of the transfer." Does this mean if a prefix is transferred into the RIPE region which currently has a ROUTE(6) object with the source 'RIPE-NONAUTH' this object will be re-tagged with the source 'RIPE'? If so are we giving a label of legitimacy to an object that was not properly authenticated?
I think Denis spotted a potential process bug here indeed. When a prefix moves from non-RIPE to RIPE managed, and a (partially) covering object exists in the RIPE DB, I think a number of things come to mind: a) the 'source:' tag should not change until the owner confirms that the route object is what it should be. (Of course the RIPE software can facilitate this as a step in the transfer process, in the majority of cases the 'route:' object is likely to need an update') b) if the prefix becomes RIPE managed space, the owner should have the ability to nuke whatever 'route:' objects exist in the RIPE DB with 'source: RIPE-NONAUTH' - even if the 'new' owner isn't a maintainer. I think a lot here comes down to good UI design and clear communication from RIPE NCC's systems to the end user to help conver/transition those 'nonauth' route objects into something that was sanctioned by the owner. Kind regards, Job
Hi Job Unless it has been modified recently there is the reclaim functionality that will allow the resource holder to delete the ROUTE(6) object.https://labs.ripe.net/Members/denis/reclaim-functionality-for-resource-holde... But this does rely on the new resource holder knowing the 'potentially rogue' ROUTE(6) object exists. So maybe it is down to a procedural or administrative issue around the transfer process. cheersdenisco-chair DB WG From: Job Snijders <job@instituut.net> To: denis walker <ripedenis@yahoo.co.uk> Cc: Tim Bruijnzeels <tim@ripe.net>; Database WG <db-wg@ripe.net> Sent: Thursday, 11 January 2018, 0:42 Subject: Re: [db-wg] NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request Hi Tim, Denis, On Wed, Jan 10, 2018 at 11:33:10PM +0000, denis walker via db-wg wrote:
I just noticed the comment below:"In case of inter-RIR transfers of live networks, ROUTE(6) objects are sometimes preserved for the transferred prefix(es). If so, they will be moved between the ‘RIPE’ and ‘RIPE-NONAUTH’ sections according to the direction of the transfer." Does this mean if a prefix is transferred into the RIPE region which currently has a ROUTE(6) object with the source 'RIPE-NONAUTH' this object will be re-tagged with the source 'RIPE'? If so are we giving a label of legitimacy to an object that was not properly authenticated?
I think Denis spotted a potential process bug here indeed. When a prefix moves from non-RIPE to RIPE managed, and a (partially) covering object exists in the RIPE DB, I think a number of things come to mind: a) the 'source:' tag should not change until the owner confirms that the route object is what it should be. (Of course the RIPE software can facilitate this as a step in the transfer process, in the majority of cases the 'route:' object is likely to need an update') b) if the prefix becomes RIPE managed space, the owner should have the ability to nuke whatever 'route:' objects exist in the RIPE DB with 'source: RIPE-NONAUTH' - even if the 'new' owner isn't a maintainer. I think a lot here comes down to good UI design and clear communication from RIPE NCC's systems to the end user to help conver/transition those 'nonauth' route objects into something that was sanctioned by the owner. Kind regards, Job
On Thu, Jan 11, 2018 at 01:17:09AM +0000, denis walker wrote:
Unless it has been modified recently there is the reclaim functionality that will allow the resource holder to delete the ROUTE(6) object https://labs.ripe.net/Members/denis/reclaim-functionality-for-resource-holde... But this does rely on the new resource holder knowing the 'potentially rogue' ROUTE(6) object exists. So maybe it is down to a procedural or administrative issue around the transfer process.
Good pointer, perhaps the issue is resolved if "towards RIPE NCC"-migrations are procedurally forced to go through the 'reclaim' process for ROUTE(6) objects, to ensure no objects exist that the (new) owner didn't approve of? Kind regards, Job
Hi Job, all,
On 11 Jan 2018, at 02:27, Job Snijders <job@instituut.net> wrote:
On Thu, Jan 11, 2018 at 01:17:09AM +0000, denis walker wrote:
Unless it has been modified recently there is the reclaim functionality that will allow the resource holder to delete the ROUTE(6) object https://labs.ripe.net/Members/denis/reclaim-functionality-for-resource-holde... But this does rely on the new resource holder knowing the 'potentially rogue' ROUTE(6) object exists. So maybe it is down to a procedural or administrative issue around the transfer process.
Good pointer, perhaps the issue is resolved if "towards RIPE NCC"-migrations are procedurally forced to go through the 'reclaim' process for ROUTE(6) objects, to ensure no objects exist that the (new) owner didn't approve of?
The ROUTE(6) objects are not always kept. In my understanding this is a case by case decision, based on the dialogue we have with involved parties during the transfer. Usually they are deleted, but if the parties wish to keep the ROUTE objects we can. This applies only really to the transfer of live networks, which are rare. They will then be moved from “RIPE” to “RIPE-NONAUTH” or vice versa. ROUTE(6) objects moved into “RIPE” space can be reclaimed as Denis pointed out. For objects moving out of the RIPE region there will be no reclaim available (except by RIPE NCC), so in this case it’s important to verify that the recipient has, or will have, their MAINTAINER added to the object. Of course it would also be good form to add the recipient’s MAINTAINER for a transfer into or inside of the RIPE region - the reclaim will work, but will also leave a window where no object(s) exist until they are recreated and this could lead to outages in case a live network is transferred. As I mentioned these cases are rare, and they are dealt with on a case by case basis. We could formalise the process more I suppose, but I believe that so-far we have always been able to find an agreeable solution with all parties involved. Kind regards, Tim
Kind regards,
Job
participants (11)
-
Alex Band -
Daniel Shaw -
denis walker -
George Michaelson -
Horváth Ágoston János -
Job Snijders -
Job Snijders -
Nick Hilliard -
Randy Bush -
Tim Bruijnzeels -
William Sylvester