a question to the WG would be whether this is
actually a desirable way to do this, or if other ways should be considered
instead.
In conclusion, we believe that this space is not yet sufficiently understood
and we encourage discussion on this in the WG before we try to implement this.
Kind reg
Tim Bruijnzeels
Principal Engineer RPKI
RIPE NCC
> On 16 Apr 2024, at 21:32, Tim Bruijnzeels wrote:
>
> Dear colleagues,
>
> We have published an updated draft of the "RIPE NCC Certification Practice
> Statement (CPS) for the Resource Public Key Infrastructure (RPKI)" for
on of RPKI and is provided
for transparency.
We invite everyone to review the updated draft and let us know on the mailing
list if they have any comments, questions or concerns. If no significant issues
are raised then we plan to publish the draft CPS as a RIPE Document on 30 April
2024.
Kind reg
Hi Klaus, all,
> On 12 Dec 2022, at 12:12, Klaus Darilion via routing-wg
> wrote:
> ...
> Is such monitoring already available and I only have to subcribe somewhere
> (free or comemrcial)? Do I miss something? Any hints what I should do before
> and after creating the ROAs?
BGP alerter and
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
> On 11 Oct 2021, at 12:45, Matthew Walster wrote:
>
> I genuinely don't understand the reason for obstruction here, what am I
> missing?
Perhaps this sentence could have made clear that I am not 'obstructing':
"In that context, I am not against BGPSec as such, there are just things
tep.
> At some point the community will do some testing, find bugs in current
> implementations that the RFC authors didn't foresee .. that is how things go
> .. we fix shizzle.
>
> Hope that this clarifies.
>
> Just my 2cp,
>
> Reg
Dear all,
I would like to support this proposal.
As an implementer of an open-source RPKI CA I find that a large part of the
support questions
that we get, and the hesitation to run a delegated CA, stems from the
requirement to not
just run a CA, which can even be offline between signing
Hi Randy, all,
> On 6 Oct 2021, at 17:10, Randy Bush wrote:
>
>> A fundamental issue that I see is that BGPSec validation only has
>> 'valid' or 'invalid'.
>
> just as ROV has: Valid and Invalid.
>
> hard to have other states in a crypto-based validation; though i have
> faith that some
> On 6 Oct 2021, at 12:55, Matthew Walster wrote:
>
> To me, there's two main issues with BGPsec, and that is the memory
> requirement of storing all the published keys, and the CPU impact of signing
> and/or verifying so many things. These are things that may be addressed over
> time with
Hi Ben,
> On 10 Sep 2021, at 13:11, Ben Maddison wrote:
>
> Hi Tim,
>
> On 09/10, Tim Bruijnzeels wrote:
>>
>>
>>> On 10 Sep 2021, at 11:57, Job Snijders wrote:
>>>
>>> On Fri, Sep 10, 2021 at 11:39:39AM +0200, Tim Bruijnzeels wrote:
> On 10 Sep 2021, at 11:57, Job Snijders wrote:
>
> On Fri, Sep 10, 2021 at 11:39:39AM +0200, Tim Bruijnzeels wrote:
>> I think all would agree that transparency is good.
>>
>> A key difference between RPKI and most other PKIs is that in the RPKI
>> all
Dear Job, all,
I think all would agree that transparency is good.
A key difference between RPKI and most other PKIs is that in the RPKI all
objects
are published in the open for all the see. As you mentioned your RPKI validator
may miss intermediate state changes if it retrieves objects using
Hi Randy, all,
> On 26 Jun 2020, at 16:04, Randy Bush wrote:
>
>> Krill uses these RIS dumps too for this initial release, but we intend
>> to evolve it over the next releases with something more real-time, as
>> well as letting you plug in a local router feed
>
> drl considered this but i
Hi
> On 23 Dec 2019, at 11:39, Randy Bush wrote:
>
> erik,
>
>> Personally, I'm not in favour of this policy as I don't like the NCC
>> to start to injecting ROA's that are not allocated or assigned to
>> members or end-users.
>>
>> I think it sets the wrong precedence for the community and
Hi all,
I am not opposed to this in principle. I see some value. However, I think it
would be good to take an impact analysis into account in order to prioritise
this relative to other rpki improvements. I agree with others who have said
that there may be more valuable things for the ripe ncc
Hi,
I think it would be good to look for contact details in the authoritative whois
for the resources involved. E.g. RDAP provides a generic way to do this. In
particular maliciously created objects may have contact details in them for the
wrong people if only the RIPE (non-authoritative)
Hi
[disclaimer, I am no longer involved in RIPE NCC implementation, but I am now
involved in NLnet Labs implementation]
> On 10 Oct 2018, at 10:05, nusenu wrote:
>
> Jay Borkenhagen:
>
>> Probably a better behavior for rpki-validator-3 to take to avoid
>> needlessly filling up logs, etc.,
it a spin
you can find a link to the beta releases on GitHub, and please let us know if
you find any issues :)
https://github.com/RIPE-NCC/rpki-validator-3/wiki/RIPE-NCC-RPKI-Validator-3-beta-tester-page
Kind regards
Tim Bruijnzeels
> On 1 May 2018, at 20:44, Gert Doering <g...@space.net&
19 matches
Mail list logo
