With a preference for the hosted mode, it would be useful for RIPE to provide
this. I also think this would go a long way to ease take-up in the future. So
yes, an appetite for BGPSEC repository to be added to the RIPE RPKI dashboard.
Hi all,
Please forgive me for top-posting (and trimming the recipients list).
There seems to be support for both BGPsec in Hosted RPKI and for “Publish in
Parent" - RFC8181.
As I’m currently working on the roadmap for Q1 2022, I will discuss with the
team what needs to be done in order to imple
Matthew Walster wrote on 11/10/2021 12:46:
> ASPA without BGPsec is barely different to RPSL. Yes, I am squinting
> very hard to make that conclusion, but essentially if I have to trust
> RIPE NCC are doing the right thing with their RPKI trust anchor, I might
> as well just get the results of the
On 10/11/21 11:33 AM, Tim Bruijnzeels wrote:
Wrt BGPSec.. I am actually very happy to see that so many people are in favor of
supporting it. I hope that router vendors are watching. To the best of my
knowledge
BGPSec has only been implemented in Bird and Quagga. The main value of
supporting
BGP
in the long run, the number of routers which might have individual keys
may be on the order of the number of prefixes. we are still learning
about fragmentation as v4 use matures. i am not worried about storing
the full key set on a validating router. i am worried about crypto load
on validating
On Mon, 11 Oct 2021 at 12:29, Randy Bush wrote:
> > ASPA is orthogonal to BGPSec. It lets AS holders declare who their
> upstreams are
> > (in the context of BGP Path, not business relation). Even if this
> information is
> > not yet used in routers in an automated way, a clear text validated
> o
> ASPA without BGPsec is barely different to RPSL. Yes, I am squinting very
> hard to make that conclusion
indeed. my old eyes can not make it.
> RIPE NCC may have substantial resources, but they are applied sequentially.
> Perhaps
> RIPE NCC can shed a light on the effort involved, but I suspect it's more than
> we might think.
>
> In that context, I am not against BGPSec as such, there are just things that I
> would like to see first:
On Mon, 11 Oct 2021 at 11:52, Tim Bruijnzeels wrote:
> > 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':
>
My apologies if I'
> 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 that
On Mon, 11 Oct 2021 at 10:33, Tim Bruijnzeels wrote:
> ASPA is orthogonal to BGPSec. It lets AS holders declare who their
> upstreams are
> (in the context of BGP Path, not business relation). Even if this
> information is
> not yet used in routers in an automated way, a clear text validated outp
On Mon, Oct 11, 2021 at 11:33:40AM +0200, Tim Bruijnzeels wrote:
> Why now?
There are published RFC and running code. Time for the next step.
> RIPE NCC may have substantial resources, but they are applied
> sequentially. Perhaps RIPE NCC can shed a light on the effort
> involved, but I suspect i
> On 9 Oct 2021, at 11:13, Marco Marzetti wrote:
>
> Hello,
>
> Erik is right. BGPSec was definitely ahead of time when the IETF started
> working on it and many have marked it as bleeding edge for good reasons.The
> technologies required to support it in the wild weren't just there back th
Hello,
Erik is right. BGPSec was definitely ahead of time when the IETF started
working on it and many have marked it as bleeding edge for good reasons.The
technologies required to support it in the wild weren't just there back
then. But they might be now.The point is we don't know and we're discu
Hi Tim,
May I suggest to read the RFC's about BGPSec and spin up something in an
environment to do some testing with BGP and BGPSec.
Normally I would suggest people to do some research, but they might end up on
Facebook and in the light of last Monday .. doing research on BGP and Facebook,
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 creati
On Wed, Oct 06, 2021 at 04:08:00PM +0200, Tim Bruijnzeels wrote:
> Contrary to Route Origin Validation (with ROAs) there is no 'not
> found' state.
I don't think it is helpful to attempt to put BGPsec and ROAs in the
same equivalance class, draw parallels and then conclude that the
'not-found' st
> 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 creative types could come up with something. please
color it magenta :)
and, just
> 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
On Tue, 5 Oct 2021, 10:42 Job Snijders via routing-wg,
wrote:
> If at this point there still are undocumented gotcha's, they aren't
> gonna be found in a vacuum. Lowering barriers (by for example making it
> easier to manage BGPsec in the RPKI dashboard) will increase the number
> of people able
On Mon, Oct 04, 2021 at 11:48:12PM +0330, Ehsan Ghazizadeh wrote:
> Its an old doc worth reading.
You are offering the working group information from 2009. The same year
"Call of Duty: Modern Warfare 2" was released.
Since then, a number of IETF-consensus documents have been published.
For exampl
Hello,
Understand. Mind to explain what?
On Mon, Oct 4, 2021 at 9:51 PM Randy Bush wrote:
> > Sorry for the naive question, but why is that relevant?
>
> asking the ncc to spend resources and money on something of which we
> are not sure and for which there is no immediate need. i think we
> h
I agree with randy, the initial intention behind BGPsec is great, but i
think it's not a good fit for global routing yet, at least we must address
its issues first, also nobody knows whether it can scale enough or not.
On Mon, Oct 4, 2021, 11:21 PM Randy Bush wrote:
> > Sorry for the naive quest
> Sorry for the naive question, but why is that relevant?
asking the ncc to spend resources and money on something of which we
are not sure and for which there is no immediate need. i think we
have more work to do on bgpsec before the marketing department takes
over. i might wish it was otherwis
Hello Randy,
Sorry for the naive question, but why is that relevant?
As per my understanding the goal is to get past the chicken/egg problem by
enabling deployment of BGPSec in the wild. Not to prove if this or that
implementation is up to anyone's standards.
On Mon, Oct 4, 2021 at 7:23 PM Randy
> There already ... multiple BGPsec-capable BGP implementations
great! would you care to enumerate any production ready bgpsec
implementations.
randy
Hi Ehsan, working group,
On Mon, 4 Oct 2021 at 14:17, Ehsan Ghazizadeh wrote:
> As far as i know, no vendor supports bgpsec, so what's the point of adding
> bgpsec support to hosted rpki?
>
There already are multiple RPKI validators which support BGPsec, multiple
signers, and multiple BGPsec-c
Hi guys
As far as i know, no vendor supports bgpsec, so what's the point of adding
bgpsec support to hosted rpki?
also cause of encryption/decryption process via async encryption method,
it's a resource intensive process so not all routers are able to handle it,
also the more important part is bg
Le 01/10/2021 à 17:06, ma...@lamehost.it a écrit :
On Mon, 2021-09-20 at 00:28 +0200, job at fastly.com wrote:
Dear all,
[ TL;DR: What does the working group think about supporting an
extension
to the RPKI Dashboard to enable publication of BGPsec certs?
]
At the moment the hosted
On Mon, 2021-09-20 at 00:28 +0200, job at fastly.com wrote:
> Dear all,
>
> [ TL;DR: What does the working group think about supporting an
> extension
> to the RPKI Dashboard to enable publication of BGPsec certs?
> ]
>
> At the moment the hosted "RPKI Dashboard" at
> https://my.ripe.net
Hi Nick,
On Mon, Sep 20, 2021 at 03:04:17PM +0100, Nick Hilliard wrote:
> Job Snijders via routing-wg wrote on 19/09/2021 23:28:
> > BGPsec is a RPKI-based technology which enables network operators to
> > transitively validate whether a given BGP UPDATE
>
> is anyone using bgpsec in production?
Job Snijders via routing-wg wrote on 19/09/2021 23:28:
BGPsec is a RPKI-based technology which enables network operators to
transitively validate whether a given BGP UPDATE
is anyone using bgpsec in production?
Nick
Hi Rubens, others,
On Sun, Sep 19, 2021 at 08:06:54PM -0300, Rubens Kuhl wrote:
> Our experience in Brazil is that delegated RPKI is not much of an
> issue provided its software deployment is easy enough. Krill + Lagosta
> + Up/Down activation + Upwards ROA publishing adds to being really
> effect
Hi Job.
Our experience in Brazil is that delegated RPKI is not much of an
issue provided its software deployment is easy enough. Krill + Lagosta
+ Up/Down activation + Upwards ROA publishing adds to being really
effective.
The Brazilian number resources ROA repository might be useful in
seeing ho
Dear all,
[ TL;DR: What does the working group think about supporting an extension
to the RPKI Dashboard to enable publication of BGPsec certs? ]
At the moment the hosted "RPKI Dashboard" at https://my.ripe.net/#/rpki,
only permits Resource Holders to create RPKI objects of one specific
35 matches
Mail list logo
