You are here: Home > Participate > Join a Discussion > RIPE Forum
This mailing list interface will be retired once we upgrade our mailing list system. Click here to use the new RIPE NCC Forum.

Routing Working Group

Threaded
Collapse

[routing-wg] Publish in Parent - input requested

User Image

Felipe Victolla Silveira

2022-09-29 16:15:31 CET

RIPE NCC staff member

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
User Image

Erik Bais

2022-09-29 16:48:28 CET

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 _at_ ripe _dot_ net> on behalf of Felipe Victolla Silveira <fvictolla _at_ ripe _dot_ net>
Date: Thursday 29 September 2022 at 16:15
To: "routing-wg _at_ ripe _dot_ net" <routing-wg _at_ ripe _dot_ 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

Compton, Rich A

2022-09-29 18:00:08 CET

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 _at_ ripe _dot_ net> on behalf of Felipe Victolla Silveira <fvictolla _at_ ripe _dot_ net>
Date: Thursday, September 29, 2022 at 8:15 AM
To: "routing-wg _at_ ripe _dot_ net" <routing-wg _at_ ripe _dot_ 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.
User Image

Randy Bush

2022-09-29 18:43:01 CET

> If you ask me, publishing at the RIR that also provided the resources
> should be the only way $B!D(B

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$B!G(Bs 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$B!G(Bt 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

User Image

Erik Bais

2022-09-29 19:21:19 CET

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 _at_ psg _dot_ 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
User Image

Randy Bush

2022-09-29 20:46:00 CET

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

User Image

Erik Bais

2022-09-29 21:11:46 CET

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 _at_ psg _dot_ 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
User Image

David Farmer

2022-09-29 21:52:03 CET

On Thu, Sep 29, 2022 at 2:11 PM Erik Bais <ebais _at_ a2b-internet _dot_ 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 _at_ umn _dot_ 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
===============================================
User Image

Alex Le Heux

2022-09-29 22:10:24 CET

Hi Felipe,

> 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.

Would this service verify all objects and only publish and retain objects that are valid, or is the purpose to re-create a mess similar to the IRR database(s)?

Best regards,

Alex Le Heux
Tucows Inc / Ting Fiber




User Image

Erik Bais

2022-09-29 22:19:06 CET

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 _at_ umn _dot_ edu> het volgende geschreven:



On Thu, Sep 29, 2022 at 2:11 PM Erik Bais <ebais _at_ a2b-internet _dot_ comebais _at_ a2b-internet _dot_ 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 _at_ umn _dot_ eduEmail%3Afarmer _at_ umn _dot_ 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
===============================================

Jay Borkenhagen

2022-09-30 03:14:19 CET

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.



User Image

Tim Bruijnzeels

2022-09-30 09:59:55 CET

Hi,

> On 29 Sep 2022, at 16:15, Felipe Victolla Silveira <fvictolla _at_ ripe _dot_ 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 





User Image

Lukas Tribus

2022-09-30 10:29:15 CET

On Fri, 30 Sept 2022 at 09:59, Tim Bruijnzeels <tim _at_ nlnetlabs _dot_ 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

Ignas Bagdonas

2022-09-30 11:50:31 CET

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.
User Image

Felipe Victolla Silveira

2022-09-30 14:43:27 CET

RIPE NCC staff member

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 _at_ gmail _dot_ 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. 
> 
> 
> 
> 

User Image

David Farmer

2022-09-30 16:39:45 CET

On Thu, Sep 29, 2022 at 4:03 PM Erik Bais <ebais _at_ a2b-internet _dot_ 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 _at_ umn _dot_ 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
===============================================
User Image

Cynthia Revström

2022-09-30 17:18:07 CET

(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 _at_ nlnetlabs _dot_ nl> wrote:
>
> Hi,
>
> > On 29 Sep 2022, at 16:15, Felipe Victolla Silveira <fvictolla _at_ ripe _dot_ 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

User Image

Randy Bush

2022-10-01 04:51:53 CET

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

User Image

Randy Bush

2022-10-04 00:06:29 CET

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

User Image

Erik Bais

2022-10-06 14:56:57 CET

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 _at_ ripe _dot_ net> on behalf of Felipe Victolla Silveira <fvictolla _at_ ripe _dot_ net>
Date: Thursday, 29 September 2022 at 16:15
To: "routing-wg _at_ ripe _dot_ net" <routing-wg _at_ ripe _dot_ 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
User Image

Felipe Victolla Silveira

2022-10-12 16:47:47 CET

RIPE NCC staff member

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 _at_ a2b-internet _dot_ 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 _at_ ripe _dot_ net> on behalf of Felipe Victolla Silveira <fvictolla _at_ ripe _dot_ net>
> Date: Thursday, 29 September 2022 at 16:15
> To: "routing-wg _at_ ripe _dot_ net" <routing-wg _at_ ripe _dot_ 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

User Image

Randy Bush

2022-10-12 18:08:03 CET

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

User Image

Felipe Victolla Silveira

2022-10-17 14:58:14 CET

RIPE NCC staff member

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-planning-and-roadmap 

Kind regards,

Felipe Victolla Silveira
Chief Operations Officer
RIPE NCC


> On 29 Sep 2022, at 16:15, Felipe Victolla Silveira <fvictolla _at_ ripe _dot_ 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