Support for "Publish in Parent" [RPKI RFC 8181]?
Hi working group, In recent mail threads the concepts of "Hosted RPKI" and "Delegated RPKI" came up, but as mentioned by Tim and Rubens, another flavor also exists! A "hybrid" between Delegated and Hosted, informally known as "publish in parent" (aka RFC 8181 compliant Publication Services). There are multiple benefits to the general RPKI ecosystem when RIRs and NIRs support RFC 8181: * Resource Holders are relieved from the responsibility to operate always online RSYNC and RRDP servers. * Reducing the number of Publication servers reduces overall resource consumption for Relying Parties. Consolidation of Publication Servers improves efficiency and is generally considered advantageous. * Helps avoid "reinventing the wheel": it might be better to have a small group of experts build a globally performant and resillient infrastructure that serves everyone, rather than everyone building the 'same' infrastructure. Other RIRs and NIRs are also working on RFC 8181 support. RFC 8181 is relatively new so it'll take some time before we see universal availability. NIC.BR (available): https://registro.br/tecnologia/numeracao/rpki/ APNIC (available): https://blog.apnic.net/2020/11/20/apnic-now-supports-rfc-aligned-publish-in-... ARIN (planned): https://www.arin.net/participate/community/acsp/suggestions/2020/2020-1/ Is implementing RFC 8181 support something RIPE NCC should add to the https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-plann... ? What do others think? Kind regards, Job Relevant documentation: https://datatracker.ietf.org/doc/html/rfc8181
Dear Job,
Op 20 sep. 2021, om 13:26 heeft Job Snijders via routing-wg <routing-wg@ripe.net> het volgende geschreven:
Hi working group,
In recent mail threads the concepts of "Hosted RPKI" and "Delegated RPKI" came up, but as mentioned by Tim and Rubens, another flavor also exists! A "hybrid" between Delegated and Hosted, informally known as "publish in parent" (aka RFC 8181 compliant Publication Services).
There are multiple benefits to the general RPKI ecosystem when RIRs and NIRs support RFC 8181:
* Resource Holders are relieved from the responsibility to operate always online RSYNC and RRDP servers.
* Reducing the number of Publication servers reduces overall resource consumption for Relying Parties. Consolidation of Publication Servers improves efficiency and is generally considered advantageous.
* Helps avoid "reinventing the wheel": it might be better to have a small group of experts build a globally performant and resillient infrastructure that serves everyone, rather than everyone building the 'same' infrastructure.
Other RIRs and NIRs are also working on RFC 8181 support. RFC 8181 is relatively new so it'll take some time before we see universal availability.
NIC.BR (available): https://registro.br/tecnologia/numeracao/rpki/ APNIC (available): https://blog.apnic.net/2020/11/20/apnic-now-supports-rfc-aligned-publish-in-... ARIN (planned): https://www.arin.net/participate/community/acsp/suggestions/2020/2020-1/
Is implementing RFC 8181 support something RIPE NCC should add to the https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-plann... ?
What do others think?
Kind regards,
Job
Relevant documentation: https://datatracker.ietf.org/doc/html/rfc8181
Thanks for bringing this up. Please be aware that the roadmap you mentioned just shows the roadmap for the current quarter and not for a longer period. If you see something missing there, it does not mean that we don’t intend to work on it, just (probably) not in the current quarter, unless it is urgent of course. The reason why we chose to publish a quarterly roadmap, is to facilitate discussions on our priorities with this working group. This is exactly why I’m very pleased that you brought up this topic (potential work item). We can always add new functionality to future roadmaps. In about a week, we will publish our roadmap for Q4. In the past, RFC8181 support (Hybrid RPKI, publish in parent, repo-as-a-service) has been asked from RIPE NCC by a few community members, for example by Benno Overeinder at RIPE82 in the routing-wg session:https://ripe82.ripe.net/archives/steno/47/ <https://ripe82.ripe.net/archives/steno/47/> I look forward to seeing a discussion here on this topic to find out if there is a broader interest. Kind regards, Nathalie Trenaman RIPE NCC
In recent mail threads the concepts of "Hosted RPKI" and "Delegated RPKI" came up, but as mentioned by Tim and Rubens, another flavor also exists! A "hybrid" between Delegated and Hosted, informally known as "publish in parent" (aka RFC 8181 compliant Publication Services).
a delegated CA may publish at their parent or anywhere else. a hosted CA may publish in an arbitrary repo, their host or in bialystok (though i am not aware of a CA which currently supports this). publication and hosting are orthogonal. randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery
On Mon, Sep 20, 2021 at 06:39:30AM -0700, Randy Bush wrote:
In recent mail threads the concepts of "Hosted RPKI" and "Delegated RPKI" came up, but as mentioned by Tim and Rubens, another flavor also exists! A "hybrid" between Delegated and Hosted, informally known as "publish in parent" (aka RFC 8181 compliant Publication Services).
a delegated CA may publish at their parent or anywhere else.
As I understand the current situation under the RIPE NCC Trust Anchor, a "Delegated CA" can publish anywhere ... *except* at their parent. Only CAs operated via the "Hosted RPKI" service can publish at rpki.ripe.net/rrdp.ripe.net. For "Delegated RPKI" users it currently is not possible to publish via rpki.ripe.net/rrdp.ripe.net. In this thread I'm to start and participate in a community dialogue, asking fellow RPKI operators what their take is on RFC 8181 in context of RIPE NCC's RPKI services, if they think it would be useful or not. What do you think? Kind regards, Job
a delegated CA may publish at their parent or anywhere else.
As I understand the current situation under the RIPE NCC Trust Anchor, a "Delegated CA" can publish anywhere ... *except* at their parent.
that is an implementation, not protool, artifact.
In this thread I'm to start and participate in a community dialogue, asking fellow RPKI operators what their take is on RFC 8181 in context of RIPE NCC's RPKI services, if they think it would be useful or not.
What do you think?
i suspect that ops who run delegated tend toward wanting control; and would be disinclined to publish back at parent. but, back in the day when we designed this stuff, we had the idea that there might be highly scaled providers of publication services not associated with any CA. </hint> randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery
What do you think?
i suspect that ops who run delegated tend toward wanting control; and would be disinclined to publish back at parent. but, back in the day when we designed this stuff, we had the idea that there might be highly scaled providers of publication services not associated with any CA. </hint>
Not our experience here in Brazil. People liked that they could run their CA at a modest CPU (Raspberry Pi, low resource VM etc.) and only allow the NIR publishing service / ROA signing service to interact with it. Rubens
i suspect that ops who run delegated tend toward wanting control; and would be disinclined to publish back at parent. but, back in the day when we designed this stuff, we had the idea that there might be highly scaled providers of publication services not associated with any CA. </hint>
Not our experience here in Brazil. People liked that they could run their CA at a modest CPU (Raspberry Pi, low resource VM etc.) and only allow the NIR publishing service / ROA signing service to interact with it.
cool. i stand corrected. randy
In recent mail threads the concepts of "Hosted RPKI" and "Delegated RPKI" came up, but as mentioned by Tim and Rubens, another flavor also exists! A "hybrid" between Delegated and Hosted, informally known as "publish in parent" (aka RFC 8181 compliant Publication Services).
There are multiple benefits to the general RPKI ecosystem when RIRs and NIRs support RFC 8181:
* Resource Holders are relieved from the responsibility to operate always online RSYNC and RRDP servers.
* Reducing the number of Publication servers reduces overall resource consumption for Relying Parties. Consolidation of Publication Servers improves efficiency and is generally considered advantageous.
* Helps avoid "reinventing the wheel": it might be better to have a small group of experts build a globally performant and resillient infrastructure that serves everyone, rather than everyone building the 'same' infrastructure.
Other RIRs and NIRs are also working on RFC 8181 support. RFC 8181 is relatively new so it'll take some time before we see universal availability.
NIC.BR (available): https://registro.br/tecnologia/numeracao/rpki/ APNIC (available): https://blog.apnic.net/2020/11/20/apnic-now-supports-rfc-aligned-publish-in-... ARIN (planned): https://www.arin.net/participate/community/acsp/suggestions/2020/2020-1/
Is implementing RFC 8181 support something RIPE NCC should add to the https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-plann... ?
What do others think?
i think it is a bit premature for the EC to make such a suggestion without consultation. randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery
Dear all, I would like to support this proposal. As an implementer of an open-source RPKI CA I find that a large part of the support questions that we get, and the hesitation to run a delegated CA, stems from the requirement to not just run a CA, which can even be offline between signing events, but a 24/7 repository as well. If this is added to the RIPE NCC RPKI backlog then I would also request that LIRs, and PI holders, can have multiple CAs publish at the RIPE NCC. The reason for this is that one of benefits of running a delegated CA lies in having the option to sub-delegate to child CAs. For example one can create child CAs with specific sub-sets of resources for departments, business units etc. To make this scale it would very beneficial if those children could publish under the publication server as well. Kind regards, Tim
On 20 Sep 2021, at 13:26, Job Snijders via routing-wg <routing-wg@ripe.net> wrote:
Hi working group,
In recent mail threads the concepts of "Hosted RPKI" and "Delegated RPKI" came up, but as mentioned by Tim and Rubens, another flavor also exists! A "hybrid" between Delegated and Hosted, informally known as "publish in parent" (aka RFC 8181 compliant Publication Services).
There are multiple benefits to the general RPKI ecosystem when RIRs and NIRs support RFC 8181:
* Resource Holders are relieved from the responsibility to operate always online RSYNC and RRDP servers.
* Reducing the number of Publication servers reduces overall resource consumption for Relying Parties. Consolidation of Publication Servers improves efficiency and is generally considered advantageous.
* Helps avoid "reinventing the wheel": it might be better to have a small group of experts build a globally performant and resillient infrastructure that serves everyone, rather than everyone building the 'same' infrastructure.
Other RIRs and NIRs are also working on RFC 8181 support. RFC 8181 is relatively new so it'll take some time before we see universal availability.
NIC.BR (available): https://registro.br/tecnologia/numeracao/rpki/ APNIC (available): https://blog.apnic.net/2020/11/20/apnic-now-supports-rfc-aligned-publish-in-... ARIN (planned): https://www.arin.net/participate/community/acsp/suggestions/2020/2020-1/
Is implementing RFC 8181 support something RIPE NCC should add to the https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-plann... ?
What do others think?
Kind regards,
Job
Relevant documentation: https://datatracker.ietf.org/doc/html/rfc8181
And while both publish in parent and BGPSec in hosted RPKI are feature requests with the same "build and they will come" spirit, I believe publish in parent to be a low hanging fruit here. That said, not being a resource holder in the RIPE region means I shouldn't try prioritizing the work of others... ;-) Rubens On Thu, Oct 7, 2021 at 11:31 AM Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
Dear all,
I would like to support this proposal.
As an implementer of an open-source RPKI CA I find that a large part of the support questions that we get, and the hesitation to run a delegated CA, stems from the requirement to not just run a CA, which can even be offline between signing events, but a 24/7 repository as well.
If this is added to the RIPE NCC RPKI backlog then I would also request that LIRs, and PI holders, can have multiple CAs publish at the RIPE NCC. The reason for this is that one of benefits of running a delegated CA lies in having the option to sub-delegate to child CAs. For example one can create child CAs with specific sub-sets of resources for departments, business units etc. To make this scale it would very beneficial if those children could publish under the publication server as well.
Kind regards, Tim
On 20 Sep 2021, at 13:26, Job Snijders via routing-wg <routing-wg@ripe.net> wrote:
Hi working group,
In recent mail threads the concepts of "Hosted RPKI" and "Delegated RPKI" came up, but as mentioned by Tim and Rubens, another flavor also exists! A "hybrid" between Delegated and Hosted, informally known as "publish in parent" (aka RFC 8181 compliant Publication Services).
There are multiple benefits to the general RPKI ecosystem when RIRs and NIRs support RFC 8181:
* Resource Holders are relieved from the responsibility to operate always online RSYNC and RRDP servers.
* Reducing the number of Publication servers reduces overall resource consumption for Relying Parties. Consolidation of Publication Servers improves efficiency and is generally considered advantageous.
* Helps avoid "reinventing the wheel": it might be better to have a small group of experts build a globally performant and resillient infrastructure that serves everyone, rather than everyone building the 'same' infrastructure.
Other RIRs and NIRs are also working on RFC 8181 support. RFC 8181 is relatively new so it'll take some time before we see universal availability.
NIC.BR (available): https://registro.br/tecnologia/numeracao/rpki/ APNIC (available): https://blog.apnic.net/2020/11/20/apnic-now-supports-rfc-aligned-publish-in-... ARIN (planned): https://www.arin.net/participate/community/acsp/suggestions/2020/2020-1/
Is implementing RFC 8181 support something RIPE NCC should add to the https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-plann... ?
What do others think?
Kind regards,
Job
Relevant documentation: https://datatracker.ietf.org/doc/html/rfc8181
On Thu, Oct 07, 2021 at 04:30:58PM +0200, Tim Bruijnzeels wrote:
If this is added to the RIPE NCC RPKI backlog then I would also request that LIRs, and PI holders, can have multiple CAs publish at the RIPE NCC. The reason for this is that one of benefits of running a delegated CA lies in having the option to sub-delegate to child CAs. For example one can create child CAs with specific sub-sets of resources for departments, business units etc. To make this scale it would very beneficial if those children could publish under the publication server as well.
You make a good point. Kind regards, Job
Sub-delegation is something that I've looked at as well. Specifically, for resource holders that are renting out IP space .. if they could sub delegate to a CA managed by the broker or the actual customer using the resource, that could be very beneficial. Just to name a specific use-case.. Erik Bais On 07/10/2021, 16:31, "routing-wg on behalf of Tim Bruijnzeels" <routing-wg-bounces@ripe.net on behalf of tim@nlnetlabs.nl> wrote: Dear all, I would like to support this proposal. As an implementer of an open-source RPKI CA I find that a large part of the support questions that we get, and the hesitation to run a delegated CA, stems from the requirement to not just run a CA, which can even be offline between signing events, but a 24/7 repository as well. If this is added to the RIPE NCC RPKI backlog then I would also request that LIRs, and PI holders, can have multiple CAs publish at the RIPE NCC. The reason for this is that one of benefits of running a delegated CA lies in having the option to sub-delegate to child CAs. For example one can create child CAs with specific sub-sets of resources for departments, business units etc. To make this scale it would very beneficial if those children could publish under the publication server as well. Kind regards, Tim > On 20 Sep 2021, at 13:26, Job Snijders via routing-wg <routing-wg@ripe.net> wrote: > > Hi working group, > > In recent mail threads the concepts of "Hosted RPKI" and "Delegated > RPKI" came up, but as mentioned by Tim and Rubens, another flavor also > exists! A "hybrid" between Delegated and Hosted, informally known as > "publish in parent" (aka RFC 8181 compliant Publication Services). > > There are multiple benefits to the general RPKI ecosystem when RIRs and > NIRs support RFC 8181: > > * Resource Holders are relieved from the responsibility to operate > always online RSYNC and RRDP servers. > > * Reducing the number of Publication servers reduces overall > resource consumption for Relying Parties. Consolidation of > Publication Servers improves efficiency and is generally > considered advantageous. > > * Helps avoid "reinventing the wheel": it might be better to have a > small group of experts build a globally performant and resillient > infrastructure that serves everyone, rather than everyone building > the 'same' infrastructure. > > Other RIRs and NIRs are also working on RFC 8181 support. RFC 8181 is > relatively new so it'll take some time before we see universal > availability. > > NIC.BR (available): https://registro.br/tecnologia/numeracao/rpki/ > APNIC (available): https://blog.apnic.net/2020/11/20/apnic-now-supports-rfc-aligned-publish-in-... > ARIN (planned): https://www.arin.net/participate/community/acsp/suggestions/2020/2020-1/ > > Is implementing RFC 8181 support something RIPE NCC should add to the > https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-plann... ? > > What do others think? > > Kind regards, > > Job > > Relevant documentation: > https://datatracker.ietf.org/doc/html/rfc8181 >
participants (6)
-
Erik Bais -
Job Snijders -
Nathalie Trenaman -
Randy Bush -
Rubens Kuhl -
Tim Bruijnzeels