Publish in Parent - input requested
Dear all, As some of you are aware, the RIPE NCC has been working on a new service for RPKI, called Publish in Parent. This service is intended for RPKI users who have chosen to run their own Certificate Authority (delegated RPKI) but don’t want to take the burden of maintaining a highly available publication point. By using this service, it will be possible for our members with delegated RPKI to publish their signed RPKI objects in the RIPE NCC repositories (RRDP and rsync) instead of maintaining their own. Following a discussion with the Executive Board in our meeting last June, we would like to ask our community for input on the requirements for this service. The service was originally designed to allow all objects to be published in our repositories, regardless of whether the associated resources are part of the RIPE NCC or another RIR, and this is how we would like to proceed. However, it has been argued that there should be a restriction in this service so that it allows only RIPE NCC resources to be published and not resources belonging to a different RIR. If you are potential user of this service, what are your expectations for its functionality? Do you want to be able to publish all your objects in RIPE NCC repositories, regardless of whether they are from the RIPE NCC or not? Or will you publish each object in the corresponding RIR repositories? Please note that we are only talking about publication. The objects out of region will be signed with their own parent certificate. If you are a developer of one of the Relying Party softwares, will the presence or absence of such a restriction impact your software package in any way? Do you expect the need to make changes, depending on the direction this takes? To make informed decisions on how we should progress with Publish in Parent, we need input from potential users of the service. Please reply with your feedback until 14 October so we can incorporate it in our planning and inform you about our progress at RIPE 85. Kind regards, Felipe Victolla Silveira Chief Operations Officer RIPE NCC
Hi Felipe, Thank you for the email. I haven’t seen any minutes of the discussion of the EB on that topic, what was the result of that discussion ? If you ask me, publishing at the RIR that also provided the resources should be the only way … As a community we have been dealing with objects in the RIPE DB for years ( and still have, if you look at the RIPE NON-Auth issues ) .. and I would like to avoid any pollution. It will make things a lot easier if the RIPE member, can only publish self-signed RIPE resources to the RIPE parent. If a particular member is both an ARIN and RIPE member, and everything is published to the RIPE parent .. and at some day, the RIPE membership is stopped.. the ARIN resources will also not be accepted anymore .. And this will have similar scenario’s the other way around .. So not for a security point of view, as each RIR will have its own certificates that will sign the respective resources .. and you could publish them theoretically everywhere .. however it will be easier to troubleshoot, if the stuff is kept within the respective RIR .. if you want to publish in parent.. It isn’t called .. Publish in Parent for no reason ... it isn’t called Publish in Uncle/Aunt .. So for publishing software, I would expect them to accept the delegation from a parent ( a RIR, which holds the delegated resources that it can then sign for .. ) and also publish it back to the respective RIR where the delegation came from. Regards, Erik Bais From: routing-wg <routing-wg-bounces@ripe.net> on behalf of Felipe Victolla Silveira <fvictolla@ripe.net> Date: Thursday 29 September 2022 at 16:15 To: "routing-wg@ripe.net" <routing-wg@ripe.net> Subject: [routing-wg] Publish in Parent - input requested Dear all, As some of you are aware, the RIPE NCC has been working on a new service for RPKI, called Publish in Parent. This service is intended for RPKI users who have chosen to run their own Certificate Authority (delegated RPKI) but don’t want to take the burden of maintaining a highly available publication point. By using this service, it will be possible for our members with delegated RPKI to publish their signed RPKI objects in the RIPE NCC repositories (RRDP and rsync) instead of maintaining their own. Following a discussion with the Executive Board in our meeting last June, we would like to ask our community for input on the requirements for this service. The service was originally designed to allow all objects to be published in our repositories, regardless of whether the associated resources are part of the RIPE NCC or another RIR, and this is how we would like to proceed. However, it has been argued that there should be a restriction in this service so that it allows only RIPE NCC resources to be published and not resources belonging to a different RIR. If you are potential user of this service, what are your expectations for its functionality? Do you want to be able to publish all your objects in RIPE NCC repositories, regardless of whether they are from the RIPE NCC or not? Or will you publish each object in the corresponding RIR repositories? Please note that we are only talking about publication. The objects out of region will be signed with their own parent certificate. If you are a developer of one of the Relying Party softwares, will the presence or absence of such a restriction impact your software package in any way? Do you expect the need to make changes, depending on the direction this takes? To make informed decisions on how we should progress with Publish in Parent, we need input from potential users of the service. Please reply with your feedback until 14 October so we can incorporate it in our planning and inform you about our progress at RIPE 85. Kind regards, Felipe Victolla Silveira Chief Operations Officer RIPE NCC
If you ask me, publishing at the RIR that also provided the resources should be the only way …
nope. consider that someone could put up a highly reliable publication service and i might want to use it. the protocols were designed specifically to accommodate a variety of publishers.
As a community we have been dealing with objects in the RIPE DB for years ( and still have, if you look at the RIPE NON-Auth issues ) .. and I would like to avoid any pollution.
RPKI != IRR
If a particular member is both an ARIN and RIPE member, and everything is published to the RIPE parent .. and at some day, the RIPE membership is stopped.. the ARIN resources will also not be accepted anymore .. And this will have similar scenario’s the other way around
if i run a CA, i can choose where i publish. my memory is that i can not choose to publish some produced objects in one PP and others in another PP. but my memory is not what it used to be.
It isn’t called .. Publish in Parent for no reason
correct. it is to differentiate a particular instance of publish arbitrarily, which is what the protocols provide. randy
Hi Randy, The question isn’t about some ( non-RIR ) publication point .. but if the RIPE NCC should support an open publication point .. or a more restricted one.. And I would say that a more restricted version is preferred. ( due to the number of support tickets at the NCC). If you don’t want to use PiP but rather a third party high available fancy publication service .. feel free to do so.. it is just not the question here. Regards, Erik Bais Verstuurd vanaf mijn iPhone
Op 29 sep. 2022 om 18:55 heeft Randy Bush <randy@psg.com> het volgende geschreven:
If you ask me, publishing at the RIR that also provided the resources should be the only way …
nope. consider that someone could put up a highly reliable publication service and i might want to use it. the protocols were designed specifically to accommodate a variety of publishers.
As a community we have been dealing with objects in the RIPE DB for years ( and still have, if you look at the RIPE NON-Auth issues ) .. and I would like to avoid any pollution.
RPKI != IRR
If a particular member is both an ARIN and RIPE member, and everything is published to the RIPE parent .. and at some day, the RIPE membership is stopped.. the ARIN resources will also not be accepted anymore .. And this will have similar scenario’s the other way around
if i run a CA, i can choose where i publish. my memory is that i can not choose to publish some produced objects in one PP and others in another PP. but my memory is not what it used to be.
It isn’t called .. Publish in Parent for no reason
correct. it is to differentiate a particular instance of publish arbitrarily, which is what the protocols provide.
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/routing-wg
Hi Randy,
so, you would exclude CAs which have resources from multiple RIRs?
I didn’t say that.. the question from the NCC is .. do we want to run an non restictive publication point and support whatever someone uploads to it .. or do we need to restrict it to ripe region resources.. if you want to publish self signed resources from multiple rir regions.. you are able to do so by setting up an instance per region.. or use software that can manage that by publishing the resources back to where the delegation came from.. We worked for years with irrdb’s like radb that would accept everything from everywhere .. I hoped we learned something from that mess at the design table .. So again, not excluding anyone .. just push the stuff where it belongs … Erik Bais Verstuurd vanaf mijn iPhone
Op 29 sep. 2022 om 20:46 heeft Randy Bush <randy@psg.com> het volgende geschreven:
hi erik,
if i run a CA, i can choose where i publish. my memory is that i can not choose to publish some produced objects in one PP and others in another PP. but my memory is not what it used to be.
so, you would exclude CAs which have resources from multiple RIRs? nice.
randy
On Thu, Sep 29, 2022 at 2:11 PM Erik Bais <ebais@a2b-internet.com> wrote:
Hi Randy,
so, you would exclude CAs which have resources from multiple RIRs?
I didn’t say that.. the question from the NCC is .. do we want to run an non restictive publication point and support whatever someone uploads to it .. or do we need to restrict it to ripe region resources..
if you want to publish self signed resources from multiple rir regions.. you are able to do so by setting up an instance per region.. or use software that can manage that by publishing the resources back to where the delegation came from..
We worked for years with irrdb’s like radb that would accept everything from everywhere .. I hoped we learned something from that mess at the design table ..
So again, not excluding anyone .. just push the stuff where it belongs …
Erik Bais
A ROA or Route Origin Authorization is an attestation of a BGP route announcement. It attests that the origin AS number is authorized to announce the prefix(es). Both the AS number and the prefix(es) are resources issued by an RIR. Are you saying both the AS number and the prefix(es) for ROA must be issued by RIPE to be accepted? I think that would be overly restrictive. I could see maybe only accepting ROAs authorizing address resources that RIPE has issued. Or am I missing something? I'm admittedly an amateur when it comes to RPKI. Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
Hi David,
Both the AS number and the prefix(es) are resources issued by an RIR. Are you saying both the AS number and the prefix(es) for ROA must be issued by RIPE to be accepted? I think that would be overly restrictive.
I could see maybe only accepting ROAs authorizing address resources that RIPE has issued.
That was exactly what I had in mind as well.. as per ROA’s, filter to accept only what was allocated / assigned by the RIPE NCC. The AS nr could be from any rir. Regards, Erik Verstuurd vanaf mijn iPhone Op 29 sep. 2022 om 21:52 heeft David Farmer <farmer@umn.edu> het volgende geschreven: On Thu, Sep 29, 2022 at 2:11 PM Erik Bais <ebais@a2b-internet.com<mailto:ebais@a2b-internet.com>> wrote: Hi Randy,
so, you would exclude CAs which have resources from multiple RIRs?
I didn’t say that.. the question from the NCC is .. do we want to run an non restictive publication point and support whatever someone uploads to it .. or do we need to restrict it to ripe region resources.. if you want to publish self signed resources from multiple rir regions.. you are able to do so by setting up an instance per region.. or use software that can manage that by publishing the resources back to where the delegation came from.. We worked for years with irrdb’s like radb that would accept everything from everywhere .. I hoped we learned something from that mess at the design table .. So again, not excluding anyone .. just push the stuff where it belongs … Erik Bais A ROA or Route Origin Authorization is an attestation of a BGP route announcement. It attests that the origin AS number is authorized to announce the prefix(es). Both the AS number and the prefix(es) are resources issued by an RIR. Are you saying both the AS number and the prefix(es) for ROA must be issued by RIPE to be accepted? I think that would be overly restrictive. I could see maybe only accepting ROAs authorizing address resources that RIPE has issued. Or am I missing something? I'm admittedly an amateur when it comes to RPKI. Thanks -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
On Thu, Sep 29, 2022 at 4:03 PM Erik Bais <ebais@a2b-internet.com> wrote:
Hi David,
Both the AS number and the prefix(es) are resources issued by an RIR. Are you saying both the AS number and the prefix(es) for ROA must be issued by RIPE to be accepted? I think that would be overly restrictive.
I could see maybe only accepting ROAs authorizing address resources that RIPE has issued.
That was exactly what I had in mind as well.. as per ROA’s, filter to accept only what was allocated / assigned by the RIPE NCC. The AS nr could be from any rir.
Thank you for clarifying your intent; while I think this policy could have its reasons, it still might be a little bit too restrictive, at least without a more definitive reason for only allowing RIPE-issued address resources to be published through the RIPE publication service. For example, if I have ten address blocks from RIPE and one address block from ARIN, I don't see the harm in allowing the publishing of one ARIN block through the RIPE service. If there is harm from allowing this, please help me understand it. Nevertheless, it seems rational to require at least some of the resources in the publication set to have been issued by RIPE as a requirement to use the RIPE publication service. Or, stated conversely, it doesn't make sense to allow the use of the RIPE publication service for resources with no nexus to RIPE. Maybe a slightly more specific and restrictive way to say this is; all ROAs published through the RIPE service must have a nexus with RIPE resources; that is, either the prefix, the ASN, or both are RIPE-issued resources. However, ROAs, where both the ASN and the prefix are not RIPE resources, are not allowed to use the RIPE publication service. Thanks Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
Erik Bais writes:
We worked for years with irrdb’s like radb that would accept everything from everywhere .. I hoped we learned something from that mess at the design table ..
So again, not excluding anyone .. just push the stuff where it belongs …
Again, RPKI != IRR. In RPKI, if one publishes records that do not have in place the requisite chains of certificates, etc., from the root(s) to the INR, the records will not validate, and the rest of the world will know not to use them. RPKI achieves this by virtue of the contents of the records themselves -- it does not rely at all on knowing who operates the publication point where the records were found. The term "Publish in Parent" is an inexact term, so let's not read too much into it. I doubt any RIR would extend such a service to a party having no INRs from that RIR, so in that regard it _is_ "Publish in Parent", but extrapolating that the name requires that INRs from only this RIR are eligible is a taking things too far. Think of it this way: as part of performing their RPKI duties, RIRs must (a) produce RPKI objects, and (b) make those RPKI objects available at any time to relying parties all around the world. RIRs can delegate the generation of certain objects to their children, but they can also offer to publish the RPKI objects generated by those children using the RIR's maximally-available publication infrastructure -- regardless of the contents of those records. It would actually be more work for an RIR to filter out any records provided by their children having to do with INRs coming from other RIRs, than it would be to accept all records the child provides. There need not be a direct relationship between the INRs issued by an RIR and the RPKI records found at their "Publish in Parent" repository. Please do not impose one. Thanks. Jay B. PS: Watch RP logs for a while, and you'll soon grow disappointed by the number of delegated CAs -- those who attempt to publish their own records -- that are not as reachable as they should be. It would be far better for most folks to publish their records using a professionally-operated publication service. Let's not make things any more difficult for delegated CAs to use well-run publication points being offered by folks like the RIPE NCC.
I would suggest that you allow multiple CAs to publish to your publication server/repository. This will allow operators to create child CAs in krill (or other CAs) and assign prefixes from the parent CA to these child CAs. The child CAs can then be assigned to various business units within an organization. Each business unit can then be responsible for the generation/maintenance of their own ROAs. Also, I suggest that the industry standardize on a term used for this service. I am partial to the term “hybrid” which ARIN and others are using. The three options being hosted, delegated, and hybrid. “Publish in Parent” seems like a mouthful. Maybe we can compress it to “PiP”? 😊 -Rich From: routing-wg <routing-wg-bounces@ripe.net> on behalf of Felipe Victolla Silveira <fvictolla@ripe.net> Date: Thursday, September 29, 2022 at 8:15 AM To: "routing-wg@ripe.net" <routing-wg@ripe.net> Subject: [EXTERNAL] [routing-wg] Publish in Parent - input requested CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance. Dear all, As some of you are aware, the RIPE NCC has been working on a new service for RPKI, called Publish in Parent. This service is intended for RPKI users who have chosen to run their own Certificate Authority (delegated RPKI) but don’t want to take the burden of maintaining a highly available publication point. By using this service, it will be possible for our members with delegated RPKI to publish their signed RPKI objects in the RIPE NCC repositories (RRDP and rsync) instead of maintaining their own. Following a discussion with the Executive Board in our meeting last June, we would like to ask our community for input on the requirements for this service. The service was originally designed to allow all objects to be published in our repositories, regardless of whether the associated resources are part of the RIPE NCC or another RIR, and this is how we would like to proceed. However, it has been argued that there should be a restriction in this service so that it allows only RIPE NCC resources to be published and not resources belonging to a different RIR. If you are potential user of this service, what are your expectations for its functionality? Do you want to be able to publish all your objects in RIPE NCC repositories, regardless of whether they are from the RIPE NCC or not? Or will you publish each object in the corresponding RIR repositories? Please note that we are only talking about publication. The objects out of region will be signed with their own parent certificate. If you are a developer of one of the Relying Party softwares, will the presence or absence of such a restriction impact your software package in any way? Do you expect the need to make changes, depending on the direction this takes? To make informed decisions on how we should progress with Publish in Parent, we need input from potential users of the service. Please reply with your feedback until 14 October so we can incorporate it in our planning and inform you about our progress at RIPE 85. Kind regards, Felipe Victolla Silveira Chief Operations Officer RIPE NCC E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
Hi,
On 29 Sep 2022, at 16:15, Felipe Victolla Silveira <fvictolla@ripe.net> wrote:
The service was originally designed to allow all objects to be published in our repositories, regardless of whether the associated resources are part of the RIPE NCC or another RIR, and this is how we would like to proceed. However, it has been argued that there should be a restriction in this service so that it allows only RIPE NCC resources to be published and not resources belonging to a different RIR.
I disagree with introducing restrictions on principle. This creates a barrier to entry that is not helpful in reducing the number of RPKI repositories - and the amount and reliability of these repositories is a mess and a concern. Furthermore, if I am a member under multiple RIRs I would like to use the repository with the best service level and availability. And, yes, if $cdn would offer a service with higher quality then I might use that. I disagree that having out-of-region objects in the RIPE NCC RPKI repository creates a mess. The comparison with IRR is wrong for a number of reasons. Most importantly IRR objects are human readable text files which are trusted because of where they are found. This is not true for RPKI. RPKI objects are intended for machine (relying party/validator) parsing, they are signed and they are validated. It does not matter where they are found: rsync, rrdp, another continent, printed on a t-shirt.. They can always be validated downwards from a Trust Anchor and the chain of trust will be known and verifiable. We call this "object security". This separation of concerns between RPKI CAs and Publication Servers was very much in the minds of the people designing the relevant protocols for this (RFC 8181, 8183). The freedom to publish all things in a repository that is separate from the parent (preferably a repository with the best quality) was treated as a requirement rather than a bug. As a result the standards have no support for expressing restrictions during setup time, nor at run-time. There is nothing in the RFC 8183 "Repository Response" that informs about any restrictions (as mentioned above, by design). So, if non-standard restrictions are added, then there is nothing that the CA software can do to prevent that the wrong repository is associated in the context of a parent. In fact, if the publication server just checks resources then publication of a manifest and CRL under the certificate received from another parent will still be accepted (manifest just say 'inherit resources'). But then when a ROA is published this would result in a runtime error. The error codes (section 2.5 RFC 8181) have no useful signal. This issue becomes even harder if there are sub-delegated "grand-children" under the LIR. There was a request to support this model and allow them to publish in the RIPE NCC repository. This model can be quite useful as it would allow delegating the control of specific resources to dedicated business units and/or customers. Requiring them to run their own publication server is huge barrier. But - how would they know what can be published? They don't even know (based on current standards) who their grand-parent is - so matching parent to repository is not trivial. Furthermore, while it may be tempting to add validation concerns to the publication server, this is not without risks either. What happens if a publication server cannot parse an object? Perhaps because it's a new object type, or perhaps it has a bug. Would it now start to reject the content for a CA? How would the CA know, and what can they do? This introduces more fragility. So, to summarise for now.. these restrictions are in my view not needed and they do more harm than good. They are also unimplementable under the current standards. If restrictions such as these should exist, then the standards need to be updated, i.e. a discussion in the IETF would be required. Tim
On Fri, 30 Sept 2022 at 09:59, Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
I disagree that having out-of-region objects in the RIPE NCC RPKI repository creates a mess. The comparison with IRR is wrong for a number of reasons.
I completely agree, the comparison with IRR is wrong and makes no sense at all. We are talking about RPKI, not IRR2. The objections raised are relevant if we would spin up a new IRR database, but that is not what we are doing here. If we overly restrict RIPE services, then new external services need to cover for this, just like RADB and friends are covering for the lack of ARIN features today (or in the past) in the IRR world. A lot of people spinning up their own http/rsync infrastructure is a nightmare. Just think of all the connections and reliability issues of CAs in validator outputs we have today. And I don't think the number of organizations operating across multiple RIR regions (or more specifically: working with resources from multiple RIR regions) is that low. Lukas
(re-sent due to issue with list and rephrasing) I agree with Tim here and do not support any such restrictions. I also think that the service should be available to anyone, not just LIRs. As Tim and others have mentioned it doesn't make sense to compare RPKI and IRR because RPKI doesn't rely on where the information is published. If there are any arguments for restricting that are not based on comparisons with IRR then I would very much like to hear them. -Cynthia On Fri, Sep 30, 2022 at 10:00 AM Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
Hi,
On 29 Sep 2022, at 16:15, Felipe Victolla Silveira <fvictolla@ripe.net> wrote:
The service was originally designed to allow all objects to be published in our repositories, regardless of whether the associated resources are part of the RIPE NCC or another RIR, and this is how we would like to proceed. However, it has been argued that there should be a restriction in this service so that it allows only RIPE NCC resources to be published and not resources belonging to a different RIR.
I disagree with introducing restrictions on principle. This creates a barrier to entry that is not helpful in reducing the number of RPKI repositories - and the amount and reliability of these repositories is a mess and a concern. Furthermore, if I am a member under multiple RIRs I would like to use the repository with the best service level and availability. And, yes, if $cdn would offer a service with higher quality then I might use that.
I disagree that having out-of-region objects in the RIPE NCC RPKI repository creates a mess. The comparison with IRR is wrong for a number of reasons.
Most importantly IRR objects are human readable text files which are trusted because of where they are found. This is not true for RPKI. RPKI objects are intended for machine (relying party/validator) parsing, they are signed and they are validated. It does not matter where they are found: rsync, rrdp, another continent, printed on a t-shirt.. They can always be validated downwards from a Trust Anchor and the chain of trust will be known and verifiable. We call this "object security".
This separation of concerns between RPKI CAs and Publication Servers was very much in the minds of the people designing the relevant protocols for this (RFC 8181, 8183). The freedom to publish all things in a repository that is separate from the parent (preferably a repository with the best quality) was treated as a requirement rather than a bug.
As a result the standards have no support for expressing restrictions during setup time, nor at run-time. There is nothing in the RFC 8183 "Repository Response" that informs about any restrictions (as mentioned above, by design). So, if non-standard restrictions are added, then there is nothing that the CA software can do to prevent that the wrong repository is associated in the context of a parent. In fact, if the publication server just checks resources then publication of a manifest and CRL under the certificate received from another parent will still be accepted (manifest just say 'inherit resources'). But then when a ROA is published this would result in a runtime error. The error codes (section 2.5 RFC 8181) have no useful signal.
This issue becomes even harder if there are sub-delegated "grand-children" under the LIR. There was a request to support this model and allow them to publish in the RIPE NCC repository. This model can be quite useful as it would allow delegating the control of specific resources to dedicated business units and/or customers. Requiring them to run their own publication server is huge barrier. But - how would they know what can be published? They don't even know (based on current standards) who their grand-parent is - so matching parent to repository is not trivial.
Furthermore, while it may be tempting to add validation concerns to the publication server, this is not without risks either. What happens if a publication server cannot parse an object? Perhaps because it's a new object type, or perhaps it has a bug. Would it now start to reject the content for a CA? How would the CA know, and what can they do? This introduces more fragility.
So, to summarise for now.. these restrictions are in my view not needed and they do more harm than good. They are also unimplementable under the current standards. If restrictions such as these should exist, then the standards need to be updated, i.e. a discussion in the IETF would be required.
Tim
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/routing-wg
Hi there. Following a discussion with the Executive Board in our meeting last June,
we would like to ask our community for input on the requirements for this service. The service was originally designed to allow all objects to be published in our repositories, regardless of whether the associated resources are part of the RIPE NCC or another RIR, and this is how we would like to proceed. However, it has been argued that there should be a restriction in this service so that it allows only RIPE NCC resources to be published and not resources belonging to a different RIR.
Could you clarify the reasons of why the question of changing the current planned model has been discussed by the board - is that based on resource projections for supporting the service going forward, is that due to possible legal aspects, and also what kind of arguments have been raised to the board for initiating such a change? Backing of a need for such planned changes by actual operational data would be highly appreciated and would bring in clarity to the community on the scope and justification of the changes proposed.
If you are potential user of this service, what are your expectations for its functionality? Do you want to be able to publish all your objects in RIPE NCC repositories, regardless of whether they are from the RIPE NCC or not? Or will you publish each object in the corresponding RIR repositories? Please note that we are only talking about publication. The objects out of region will be signed with their own parent certificate.
Working group - please raise your opinions, with elaboration, and specifically in the context of long term usage interface stability for such a service. And please focus on the service consumption and operation - while inventing yet another protocol extension is certainly fun, that is a secondary aspect, while the primary one is on the architectural decision.
To make informed decisions on how we should progress with Publish in Parent, we need input from potential users of the service. Please reply with your feedback until 14 October so we can incorporate it in our planning and inform you about our progress at RIPE 85.
Given this timing, the upcoming RIPE85 routing WG meeting will not discuss this topic (plus the agenda is already full anyway, and the meeting slot is shorter than usual). Depending on how the discussion develops here on the mailing list, it might be practical to have a longer period for this to get resolved.
Hi Ignas, We presented the Terms and Conditions to the Board. At that stage one of the elements of the T&C brought up the topic of whether this could be a member agreement or whether it needed to be an agreement that could be signed by non-members. And that brought us to a discussion on whether Publish in Parent should be available for RIPE NCC resources only or also resources from other RIRs. At the subsequent Board meeting this Monday, it was agreed by all that bringing this to the community and soliciting input from potential users would be the best way to get consensus on the right way forward. Kind regards, Felipe
On 30 Sep 2022, at 11:50, Ignas Bagdonas <ibagdona.ripe@gmail.com> wrote:
Hi there.
Following a discussion with the Executive Board in our meeting last June, we would like to ask our community for input on the requirements for this service. The service was originally designed to allow all objects to be published in our repositories, regardless of whether the associated resources are part of the RIPE NCC or another RIR, and this is how we would like to proceed. However, it has been argued that there should be a restriction in this service so that it allows only RIPE NCC resources to be published and not resources belonging to a different RIR.
Could you clarify the reasons of why the question of changing the current planned model has been discussed by the board - is that based on resource projections for supporting the service going forward, is that due to possible legal aspects, and also what kind of arguments have been raised to the board for initiating such a change? Backing of a need for such planned changes by actual operational data would be highly appreciated and would bring in clarity to the community on the scope and justification of the changes proposed.
If you are potential user of this service, what are your expectations for its functionality? Do you want to be able to publish all your objects in RIPE NCC repositories, regardless of whether they are from the RIPE NCC or not? Or will you publish each object in the corresponding RIR repositories? Please note that we are only talking about publication. The objects out of region will be signed with their own parent certificate.
Working group - please raise your opinions, with elaboration, and specifically in the context of long term usage interface stability for such a service. And please focus on the service consumption and operation - while inventing yet another protocol extension is certainly fun, that is a secondary aspect, while the primary one is on the architectural decision.
To make informed decisions on how we should progress with Publish in Parent, we need input from potential users of the service. Please reply with your feedback until 14 October so we can incorporate it in our planning and inform you about our progress at RIPE 85.
Given this timing, the upcoming RIPE85 routing WG meeting will not discuss this topic (plus the agenda is already full anyway, and the meeting slot is shorter than usual). Depending on how the discussion develops here on the mailing list, it might be practical to have a longer period for this to get resolved.
aol ignas < rant > sorry, i may be misusing "CA." an op's server (a Certificate Authority) holds one or more certificates; at least one per parent for which it has subsidiary objects. [ CA != cert ] i do not use the term 'operator' because an operator could have multiple whole CA set-ups. ] each certificate has a publication point (a directory?). in theory, each cert in a multi-cert CA _could_ use a separate publication service, but i am not aware of any CA software which has ever supported this. one publication service can host multiple publication points for the multiple certs of that CA and for multiple CAs. and, when an 8183 request arrives at a publication server, it would be able to accept the request only if the requester was a descendent of the favorite (e.g. parent) CA of the publisher, or payes them a lot of zlotys, or whatever. the problem is that wanting to separate them all to have some kind of publication racial purity is inappropriate because, unlike IRR, RPKI subtrees are all supposed to be equally rigorous. unlike the IRR (where it all sucks), the NCC's subtree is no better than ARIN's or LACNIC's. my worry is that complicating the CA and publication software to maintain racial purity in publication will encourage an already broken ecosystem to be even more fragile and more vulnerable. there are a bunch of folk measuring the ecosystem and the software components, and it is horrifying. nothing is rigorously 100% correct. i do not want to encourage CA components to make it even worse, or the NCC to make their publication service even more brittle by asking it to detect racial impurities that don't make a damned bit of difference. randy
a friend has asked me about the possibility of DoS of a CA pushing random dren to a publication point; e.g. rsc signed kernel binaries, etc. obviously, it would have been unwise for the 8181 publication protocol to enumerate the allowed objects, or it would need to be updated every time the ietf sausage machine defined a new object (router key, aspa, etc.) but 8181 does provide for error handling. it seems obvious that a publisher reject a request to publish an object other than a formally correct rpki object. e.g. it should not accept the kernel blob. interesting, we do not have a document enumerating formal rpki signed objects. https://www.iana.org/assignments/rpki/rpki.xhtml#signed-objects is missing a few, e.g. certificates, crls. i have taken this up with the powers that be. randy
HI Felipe, Could you provide some insight on how the authorization for the PiP system is envisioned ? We have been discussing that the PiP implementation is planned for RIPE members, which to my view would mean that PiP is only available for LIR’s in good standing. That would also mean that if you are not an LIR anymore, that you lose the ability to upload objects ( correct ? ) Or .. is the authorization linked to a RIPE NCC SSO account, ( which is free…) and it will also be available for RIPE PI space holders or legacy space holders .. I would say that it would be better for the community to have the authorization for this with a free to setup NCC SSO account, as those don’t need to be linked to a LIR .. and it will allow for less issues if the LIR closes for some reason . . . I would also think that if someone would like to use the publication point, it should have something to do with some RIPE resource … Looking forward to your reply, Regards, Erik Bais From: routing-wg <routing-wg-bounces@ripe.net> on behalf of Felipe Victolla Silveira <fvictolla@ripe.net> Date: Thursday, 29 September 2022 at 16:15 To: "routing-wg@ripe.net" <routing-wg@ripe.net> Subject: [routing-wg] Publish in Parent - input requested Dear all, As some of you are aware, the RIPE NCC has been working on a new service for RPKI, called Publish in Parent. This service is intended for RPKI users who have chosen to run their own Certificate Authority (delegated RPKI) but don’t want to take the burden of maintaining a highly available publication point. By using this service, it will be possible for our members with delegated RPKI to publish their signed RPKI objects in the RIPE NCC repositories (RRDP and rsync) instead of maintaining their own. Following a discussion with the Executive Board in our meeting last June, we would like to ask our community for input on the requirements for this service. The service was originally designed to allow all objects to be published in our repositories, regardless of whether the associated resources are part of the RIPE NCC or another RIR, and this is how we would like to proceed. However, it has been argued that there should be a restriction in this service so that it allows only RIPE NCC resources to be published and not resources belonging to a different RIR. If you are potential user of this service, what are your expectations for its functionality? Do you want to be able to publish all your objects in RIPE NCC repositories, regardless of whether they are from the RIPE NCC or not? Or will you publish each object in the corresponding RIR repositories? Please note that we are only talking about publication. The objects out of region will be signed with their own parent certificate. If you are a developer of one of the Relying Party softwares, will the presence or absence of such a restriction impact your software package in any way? Do you expect the need to make changes, depending on the direction this takes? To make informed decisions on how we should progress with Publish in Parent, we need input from potential users of the service. Please reply with your feedback until 14 October so we can incorporate it in our planning and inform you about our progress at RIPE 85. Kind regards, Felipe Victolla Silveira Chief Operations Officer RIPE NCC
Hi Erik, Publish in Parent does require its users to have a valid RPKI certificate for a delegated CA in order to be able to publish objects in it. That could either be a member, a PI holder (with a sponsoring LIR) or legacy holders with a contract relationship. A user can also create other publication points, for example for CAs of business units, or a (grand)child CA. In other words, in order to use the system, you either have to have a contract relationship with the RIPE NCC, be associated with a sponsoring LIR or have access delegated to you from one of these. Allowing SSO accounts without one of the above conditions would open the door to abuse, as it would be difficult, if not impossible, to track down users abusing the system. I hope that clarifies your queries, otherwise I am happy to elaborate further. Kind regards, Felipe
On 6 Oct 2022, at 14:56, Erik Bais <ebais@a2b-internet.com> wrote:
HI Felipe,
Could you provide some insight on how the authorization for the PiP system is envisioned ?
We have been discussing that the PiP implementation is planned for RIPE members, which to my view would mean that PiP is only available for LIR’s in good standing. That would also mean that if you are not an LIR anymore, that you lose the ability to upload objects ( correct ? )
Or .. is the authorization linked to a RIPE NCC SSO account, ( which is free…) and it will also be available for RIPE PI space holders or legacy space holders ..
I would say that it would be better for the community to have the authorization for this with a free to setup NCC SSO account, as those don’t need to be linked to a LIR .. and it will allow for less issues if the LIR closes for some reason . . .
I would also think that if someone would like to use the publication point, it should have something to do with some RIPE resource …
Looking forward to your reply,
Regards, Erik Bais
From: routing-wg <routing-wg-bounces@ripe.net> on behalf of Felipe Victolla Silveira <fvictolla@ripe.net> Date: Thursday, 29 September 2022 at 16:15 To: "routing-wg@ripe.net" <routing-wg@ripe.net> Subject: [routing-wg] Publish in Parent - input requested
Dear all,
As some of you are aware, the RIPE NCC has been working on a new service for RPKI, called Publish in Parent. This service is intended for RPKI users who have chosen to run their own Certificate Authority (delegated RPKI) but don’t want to take the burden of maintaining a highly available publication point. By using this service, it will be possible for our members with delegated RPKI to publish their signed RPKI objects in the RIPE NCC repositories (RRDP and rsync) instead of maintaining their own.
Following a discussion with the Executive Board in our meeting last June, we would like to ask our community for input on the requirements for this service. The service was originally designed to allow all objects to be published in our repositories, regardless of whether the associated resources are part of the RIPE NCC or another RIR, and this is how we would like to proceed. However, it has been argued that there should be a restriction in this service so that it allows only RIPE NCC resources to be published and not resources belonging to a different RIR.
If you are potential user of this service, what are your expectations for its functionality? Do you want to be able to publish all your objects in RIPE NCC repositories, regardless of whether they are from the RIPE NCC or not? Or will you publish each object in the corresponding RIR repositories? Please note that we are only talking about publication. The objects out of region will be signed with their own parent certificate.
If you are a developer of one of the Relying Party softwares, will the presence or absence of such a restriction impact your software package in any way? Do you expect the need to make changes, depending on the direction this takes?
To make informed decisions on how we should progress with Publish in Parent, we need input from potential users of the service. Please reply with your feedback until 14 October so we can incorporate it in our planning and inform you about our progress at RIPE 85.
Kind regards,
Felipe Victolla Silveira Chief Operations Officer RIPE NCC
yup. or to put it in nerdish, from 8181 The authentication and message integrity architecture of the publication protocol is essentially identical to the architecture used in [RFC6492] because the participants in this protocol are the same CA engines as in RFC 6492; this allows reuse of the same "Business PKI" (BPKI) (see Section 1.2) infrastructure used to support RFC 6492. randy
Hi all, First of all, I would like to thank you for your input and the engaged discussion. It is highly appreciated and helps us to decide how to proceed with our new service. After carefully going through the different points raised, we have decided to proceed with the deployment of the service as it currently stands, without restrictions. At the same time, we took note of opposing views and encourage you to continue the discussion here. Should the community reach consensus on implementing the restriction at a later stage, we will add this to our roadmap and implement it as part of our existing process. Our quarterly roadmaps are published at the following address: https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-plann... <https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap> Kind regards, Felipe Victolla Silveira Chief Operations Officer RIPE NCC
On 29 Sep 2022, at 16:15, Felipe Victolla Silveira <fvictolla@ripe.net> wrote:
Dear all,
As some of you are aware, the RIPE NCC has been working on a new service for RPKI, called Publish in Parent. This service is intended for RPKI users who have chosen to run their own Certificate Authority (delegated RPKI) but don’t want to take the burden of maintaining a highly available publication point. By using this service, it will be possible for our members with delegated RPKI to publish their signed RPKI objects in the RIPE NCC repositories (RRDP and rsync) instead of maintaining their own.
Following a discussion with the Executive Board in our meeting last June, we would like to ask our community for input on the requirements for this service. The service was originally designed to allow all objects to be published in our repositories, regardless of whether the associated resources are part of the RIPE NCC or another RIR, and this is how we would like to proceed. However, it has been argued that there should be a restriction in this service so that it allows only RIPE NCC resources to be published and not resources belonging to a different RIR.
If you are potential user of this service, what are your expectations for its functionality? Do you want to be able to publish all your objects in RIPE NCC repositories, regardless of whether they are from the RIPE NCC or not? Or will you publish each object in the corresponding RIR repositories? Please note that we are only talking about publication. The objects out of region will be signed with their own parent certificate.
If you are a developer of one of the Relying Party softwares, will the presence or absence of such a restriction impact your software package in any way? Do you expect the need to make changes, depending on the direction this takes?
To make informed decisions on how we should progress with Publish in Parent, we need input from potential users of the service. Please reply with your feedback until 14 October so we can incorporate it in our planning and inform you about our progress at RIPE 85.
Kind regards,
Felipe Victolla Silveira Chief Operations Officer RIPE NCC
participants (11)
-
Compton, Rich A -
Cynthia Revström -
David Farmer -
Erik Bais -
Erik Bais -
Felipe Victolla Silveira -
Ignas Bagdonas -
Jay Borkenhagen -
Lukas Tribus -
Randy Bush -
Tim Bruijnzeels