Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
Dear WG, chairs, On Mon, Oct 16, 2017 at 11:24:14PM +0000, William Sylvester via db-wg wrote:
Now that there has been substantial discussion on this topic, I wanted to try to bring the conversation back to a more practical and actionable path forward. Clearly this is a topic where there are a lot of opinions. From seeing the discussion and receiving additional feedback, I wanted to point out some re-occurring themes and request a revised proposal for working group consideration.
1) Remove the "origin:" authorization requirement. RIPE is currently the only RIR that requires this, the current implementation creates data concurrency issues across Internet databases by requiring the creation of duplicate autnums.
2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.
I’d like to seek input from the group;
- Do you feel these options are straight forward and easy to understand? - Does this provide a reasonable security posture? - Will this make a positive impact for RIPE DB and the greater Internet? - Do you support these concepts?
I fully support executing both action items. Removal of the "origin:" authorisation step will bring the RIPE IRR in line with other databases such as APNIC, RADB and as such make use of the database easier for global organisations. It also aligns with the practises observed in RPKI. Flagging "route:/route6:" objects with "RIPE-NONAUTH" when they cover non-RIPE managed space has many benefits. Setting the "source:" to represent what the data actually means, we can programmatically analyse the contents of the RIPE DB and facilitate creation of higher quality route filters, but also for instance use it as a reputation factor in spam scoring. These two options represent what currently is the lowest hanging fruit to improve in this problem space. Funny enough, neither of these items makes things more difficult for anyone involved, on the contrary - by making route: authorisation easier, _and_ showing what is authoritative data and what is not, we improve the security posture of the RIPE community. Kind regards, Job
I agree and support both 2 mentioned items. Erik Bais -----Oorspronkelijk bericht----- Van: Job Snijders [mailto:job@instituut.net] Verzonden: dinsdag 17 oktober 2017 9:53 Aan: William Sylvester <william.sylvester@addrex.net> CC: Database WG <db-wg@ripe.net> Onderwerp: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? Dear WG, chairs, On Mon, Oct 16, 2017 at 11:24:14PM +0000, William Sylvester via db-wg wrote:
Now that there has been substantial discussion on this topic, I wanted to try to bring the conversation back to a more practical and actionable path forward. Clearly this is a topic where there are a lot of opinions. From seeing the discussion and receiving additional feedback, I wanted to point out some re-occurring themes and request a revised proposal for working group consideration.
1) Remove the "origin:" authorization requirement. RIPE is currently the only RIR that requires this, the current implementation creates data concurrency issues across Internet databases by requiring the creation of duplicate autnums.
2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.
I’d like to seek input from the group;
- Do you feel these options are straight forward and easy to understand? - Does this provide a reasonable security posture? - Will this make a positive impact for RIPE DB and the greater Internet? - Do you support these concepts?
I fully support executing both action items. Removal of the "origin:" authorisation step will bring the RIPE IRR in line with other databases such as APNIC, RADB and as such make use of the database easier for global organisations. It also aligns with the practises observed in RPKI. Flagging "route:/route6:" objects with "RIPE-NONAUTH" when they cover non-RIPE managed space has many benefits. Setting the "source:" to represent what the data actually means, we can programmatically analyse the contents of the RIPE DB and facilitate creation of higher quality route filters, but also for instance use it as a reputation factor in spam scoring. These two options represent what currently is the lowest hanging fruit to improve in this problem space. Funny enough, neither of these items makes things more difficult for anyone involved, on the contrary - by making route: authorisation easier, _and_ showing what is authoritative data and what is not, we improve the security posture of the RIPE community. Kind regards, Job
I agree and support both 2 mentioned items. Erik Bais -----Oorspronkelijk bericht----- Van: Job Snijders [mailto:job@instituut.net] Verzonden: dinsdag 17 oktober 2017 9:53 Aan: William Sylvester <william.sylvester@addrex.net> CC: Database WG <db-wg@ripe.net> Onderwerp: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? Dear WG, chairs, On Mon, Oct 16, 2017 at 11:24:14PM +0000, William Sylvester via db-wg wrote:
Now that there has been substantial discussion on this topic, I wanted to try to bring the conversation back to a more practical and actionable path forward. Clearly this is a topic where there are a lot of opinions. From seeing the discussion and receiving additional feedback, I wanted to point out some re-occurring themes and request a revised proposal for working group consideration.
1) Remove the "origin:" authorization requirement. RIPE is currently the only RIR that requires this, the current implementation creates data concurrency issues across Internet databases by requiring the creation of duplicate autnums.
2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.
I’d like to seek input from the group;
- Do you feel these options are straight forward and easy to understand? - Does this provide a reasonable security posture? - Will this make a positive impact for RIPE DB and the greater Internet? - Do you support these concepts?
I fully support executing both action items. Removal of the "origin:" authorisation step will bring the RIPE IRR in line with other databases such as APNIC, RADB and as such make use of the database easier for global organisations. It also aligns with the practises observed in RPKI. Flagging "route:/route6:" objects with "RIPE-NONAUTH" when they cover non-RIPE managed space has many benefits. Setting the "source:" to represent what the data actually means, we can programmatically analyse the contents of the RIPE DB and facilitate creation of higher quality route filters, but also for instance use it as a reputation factor in spam scoring. These two options represent what currently is the lowest hanging fruit to improve in this problem space. Funny enough, neither of these items makes things more difficult for anyone involved, on the contrary - by making route: authorisation easier, _and_ showing what is authoritative data and what is not, we improve the security posture of the RIPE community. Kind regards, Job
I also agree with both items. Nobody has ever been able to give me a convincing justification for requiring the origin authorisation step for creating route objects. Removing it will bring the authorisation in line with RPKI, which can enable the RIPE NCC to create a seamless user interface for keeping route objects and RPKI ROAs in sync. This will make management of route authorisations easier and most likely increase data quality by leveraging the existing RPKI interface with route collector data and also apply it to route objects. Kind regards, Alex Band On 2017-10-17 10:16:28 CET, Erik Bais wrote:
I agree and support both 2 mentioned items.
Erik Bais
-----Oorspronkelijk bericht----- Van: Job Snijders [mailto:job _at_ instituut _dot_ net] Verzonden: dinsdag 17 oktober 2017 9:53 Aan: William Sylvester <william.sylvester _at_ addrex _dot_ net> CC: Database WG <db-wg _at_ ripe _dot_ net> Onderwerp: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
Dear WG, chairs,
On Mon, Oct 16, 2017 at 11:24:14PM +0000, William Sylvester via db-wg wrote:
Now that there has been substantial discussion on this topic, I wanted to try to bring the conversation back to a more practical and actionable path forward. Clearly this is a topic where there are a lot of opinions. From seeing the discussion and receiving additional feedback, I wanted to point out some re-occurring themes and request a revised proposal for working group consideration.
1) Remove the "origin:" authorization requirement. RIPE is currently the only RIR that requires this, the current implementation creates data concurrency issues across Internet databases by requiring the creation of duplicate autnums.
2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.
I’d like to seek input from the group;
- Do you feel these options are straight forward and easy to understand? - Does this provide a reasonable security posture? - Will this make a positive impact for RIPE DB and the greater Internet? - Do you support these concepts?
I fully support executing both action items.
Removal of the "origin:" authorisation step will bring the RIPE IRR in line with other databases such as APNIC, RADB and as such make use of the database easier for global organisations. It also aligns with the practises observed in RPKI.
Flagging "route:/route6:" objects with "RIPE-NONAUTH" when they cover non-RIPE managed space has many benefits. Setting the "source:" to represent what the data actually means, we can programmatically analyse the contents of the RIPE DB and facilitate creation of higher quality route filters, but also for instance use it as a reputation factor in spam scoring.
These two options represent what currently is the lowest hanging fruit to improve in this problem space. Funny enough, neither of these items makes things more difficult for anyone involved, on the contrary - by making route: authorisation easier, _and_ showing what is authoritative data and what is not, we improve the security posture of the RIPE community.
Kind regards,
Job
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
participants (4)
-
Alex Band -
Erik Bais -
Erik Bais -
Job Snijders