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
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
f Felipe Victolla
> Silveira
> Date: Thursday, 29 September 2022 at 16:15
> To: "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
>
something to do with some RIPE resource …
Looking forward to your reply,
Regards,
Erik Bais
From: routing-wg on behalf of Felipe Victolla
Silveira
Date: Thursday, 29 September 2022 at 16:15
To: "routing-wg@ripe.net"
Subject: [routing-wg] Publish in Parent - input requested
Dear all
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
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. ]
(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
On Thu, Sep 29, 2022 at 4:03 PM Erik Bais 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
Hi Ignas,
We presented the Terms and Conditions to the Board. At that stage one of the
elements of the T 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
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
On Fri, 30 Sept 2022 at 09:59, Tim Bruijnzeels 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
Hi,
> On 29 Sep 2022, at 16:15, Felipe Victolla Silveira 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
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
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
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
On Thu, Sep 29, 2022 at 2:11 PM Erik Bais 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
> ..
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
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
> 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
From: routing-wg on behalf of Felipe Victolla
Silveira
Date: Thursday 29 September 2022 at 16:15
To: "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, call
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
21 matches
Mail list logo
