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

Good to hear from Brazil! Indeed a number of organizations have worked hard to remove as many barriers as possible towards the Delegated RPKI. Impressive progress. My message was not intended to take away from "Delegated RPKI" deployments (I run one myself!), but rather to suggest that the "Hosted RPKI" Dashboard should _also_ make it possible to certify & publish BGPsec Router keys. I suspect that "Hosted RPKI" will always be popular: clearly many operators feel comfortable outsourcing the issuance & publication of their ROAs to the RIR. I think it is important to study feature gaps between "Hosted" and "Delegated". Kind regards, Job ps. A: What about ASPA? Q: why not both? :-) I'm working to start an IANA "Early Allocation" procedure to obtain codepoints for ASPA. When progress has been made I'll circle back to routing-wg@ in a new thread, unless someone beats me to it. :-)

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?

Not that I'm aware of, but I do know folks are actively studying the feasibility and potential benefits in prepration for potential production deployments. Still early days. I believe there are multiple barriers to BGPsec deployment in 'production' environments, one of which is that it is a bit cumbersome to certify & publish BGP router keys. Support to manage BGPsec keys via the RPKI dashboard will make it easier for people to experiment with the various open source BGPsec implementations, which in turn paves the way to wider deployment in a few years. In order to gauge uptake of BGPsec, it first should be made (more easily) available to operators. This thread is not intended as an in-depth explorations of the pro's and con's of BGPsec, but rather to inquiry whether there is any appetite to implement a (relatively simple) and standardized keying operation, and leave it up to operators to use the service or not. Kind regards, Job

Le 01/10/2021 à 17:06, marco@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 "RPKI Dashboard" at https://my.ripe.net/#/rpki, only permits Resource Holders to create RPKI objects of one specific type: ROAs. However, a wider range of RPKI cryptographic product types also exists, for example: BGPsec Router Certificates [RFC 8209].

BGPsec is a RPKI-based technology which enables network operators to transitively validate whether a given BGP UPDATE - indeed - passed through the Autonomous Systems listed in the path. One way to think of BGPsec is as an ECDSA protected network of channels between a receiving EBGP node; and one (or many) routers in the BGP route's Origin AS.

I think BGPsec can be useful to protect "private peering" at large scale, and another use case is to increase confidence in routing information distributed via IXP Route/Blackhole Servers.

Right now, routing protocol researchers and network operators wishing to publish BGPsec Router Keys, also have to learn how to master "Delegated RPKI": a deployment model with a steep learning curve. I think there are benefits to the community if RIPE NCC appends an activity to the "RPKI Planning and Roadmap" to implement procedures to sign and publish BGPsec Router Keys via a PKCS#10 / PKCS#7 exchange, callable via both API and dashboard WebUI.

What do others think?

Kind regards,

Job

Relevant documentation: https://datatracker.ietf.org/doc/html/rfc8209 https://datatracker.ietf.org/doc/html/rfc8635

Hello,

I support the idea as it would enable network operators to explore the benefits of BGPsec in production environment. And the effort sounds small Hello all,

+1 The effort to enable publication of BGPsec certs on the RPKI dashboard seems reasonable as there is already an hosted RPKI and a portal to manage ROAs. Having an hosted RPKI for BGPSec objects will help definitely operators who do not have the resources to manage a PKI

Regards

-- ------------------------------------------------------------------------ <https://franceix.net> <https://franceix.net> Simon *MUYAL* *Directeur Technique / Chief Technical Officer* Tel :*+33 1 70 61 97 74* Site : www.franceix.net <http://www.franceix.net> <https://blog.franceix.net/france-ix-and-rezopole-become-one/> <https://fr-fr.facebook.com/ixpfranceix/> <https://twitter.com/ixpfranceix> <https://www.linkedin.com/company/france-ix/?originalSubdomain=fr>

Hi Ehsan, working group, On Mon, 4 Oct 2021 at 14:17, Ehsan Ghazizadeh <ehsan.ccsp@gmail.com> 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-capable BGP implementations. Whether one likes the currently available choices is of course a somewhat subjective matter. :-) BGPsec - at present - definitely isn’t the operators “go to” tool; but the specification has been published via the IETF RFC standards track, received significant scrutiny, and multiple independent implementations have been produced. It takes a lot of community effort to go from 0 to 1, and from 1 to 100. I think adding BGPsec support to hosted RPKI management dashboards might help make BGPsec more mainstream, in turn increasing demand for additional (commercial off the shelf) implementations. The effects of obstacles to deployment often appear to compound. 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 bgpsec changes the normal behavior of bgp, for instance, update packing (update group) will be disabled.

Indeed, it is always important to use equipment suitable for the job at hand. It might make sense to keep an eye out for BGP routers with AVX512 support in their CPU, rather than attempting to retrofit this type of tech onto 32-bit PowerPC based platforms. :-) Are we just discussing the support of bgpsec certs on hosted rpki, and we

would discuss bgpsec deployment impacts and open issues later?

I believe the current discussion is about the first aspect. But I love and welcome dialogue on deployment impact and any open issues (so the community can work on addressing each and every issue)! Evaluating and (potentially) deploying BGPsec in production environments is a multi-year project, just like RPKI-based BGP Origin Validation was. Kind regards, Job

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 Bush <randy@psg.com> wrote:

...

There already ... multiple BGPsec-capable BGP implementations

great! would you care to enumerate any production ready bgpsec implementations.

randy

-- Marco

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 <randy@psg.com> 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 have more work to do on bgpsec before the marketing department takes over. i might wish it was otherwise, but ...

randy

Its an old doc worth reading. On Mon, Oct 4, 2021, 11:32 PM Marco Marzetti <marco@lamehost.it> wrote:

Hello,

Understand. Mind to explain what?

On Mon, Oct 4, 2021 at 9:51 PM Randy Bush <randy@psg.com> 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 have more work to do on bgpsec before the marketing department takes over. i might wish it was otherwise, but ...

randy

-- Marco

On Tue, 5 Oct 2021, 10:42 Job Snijders via routing-wg, <routing-wg@ripe.net> 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 to take a look at BGPsec, and subsequently improve the technology.

In general, I'm opposed to rushing into adding support for experimental technologies in things like dashboards, as it can overcomplicate matters and make people wary of giving things a try. I have recently taken the time to understand BGPsec, and cleared up a number of misconceptions I had around how it operates -- it's actually what most people assume RPKI OV is doing. The barrier to entry is literally just publishing public keys of the routers signing the messages, and ensuring they are made available to routers (ok, BGP daemons) to do the checking. 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 the natural progression of route processors becoming more capable (time to retire that Cyrix 200 yet?) and utilising BGPsec only on "sensitive" peers, such as at IXP route servers and with customers etc. What is abundantly clear, however, is that BGPsec will not gain any traction at all unless it is easy to try. Operating a delegated RPKI repo is sufficiently complex that most can't be bothered. That is why RPKI OV has seen the uptake it has -- there is an easier route: use the hosted repo. Considering the only thing the RPKI repo needs to support BGPsec is the router signing keys, with no risk of affecting existing ROAs etc, it seems like minimal effort to add the ability to upload keys through the dashboard. Enabling BGPsec validation on a router to try it out is then even less effort than what is required to support RPKI RTR and OV that many networks have ended up doing over the past couple of years. In my opinion, the low level of effort required to support uploading of keys to a hosted repo is more than repaid by the potential boost to support BGPsec would receive, even if BGPsec would be radically changed in the intervening time, the publication of signing keys is highly unlikely to change. Is this an action RIPE NCC *needs* to take? Of course not. I think it's well within the remit though, has precedent with the whole whois/RDAP story, does not open any "slippery slope" arguments because it's such a minor change with clear benefit, and will need to be done anyway should BGPsec gain widespread traction... As Job says, it's best to identify problems now, while it's early. It lowers the barrier to entry, which should encourage the authors of BGP daemons to support validation, and maybe even support signing themselves. There is no appreciable downside here. I would like to see router signing key publishing support in the RPKI dashboard. Matthew Walster (Now you see why I'm called waffle...)

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 as ROV has NotFound, BGPsec has not signed. randy

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, might be a different rabbit hole .. ;-) Back in 2008 we did some policy work here in the community for RPKI .. there were only a couple CLI based "validators", most routers vendors had no idea what RPKI was .. and still we asked the RIPE NCC to do work on RPKI. If you don't recall that, perhaps Alex B. can provide some history on that process __ What Job asked is to see if we should start with a similar process for BGPSec. We start with publishing and monitoring ... and who knows when and if this will become mainstream .. But if we don't start somewhere .. it will never get anywhere .. The question and discussion isn't about if someone likes BGPSec or if it will ever become mainstream .. or if someone will personally ever use it .. or if the current status of the RFC's isn't finished yet to the final version .. In order to be able to asses this for the community .. there need to be some tools in place .. to make it easier for it to even go to that step. 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, Regards, Erik Bais On 07/10/2021, 11:41, "routing-wg on behalf of Tim Bruijnzeels" <routing-wg-bounces@ripe.net on behalf of tim@nlnetlabs.nl> wrote: Hi Randy, all, > On 6 Oct 2021, at 17:10, Randy Bush <randy@psg.com> 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 creative types could come up with something. please > color it magenta :) > > and, just as ROV has NotFound, BGPsec has not signed. Please bear with me, it is not my intention to misrepresent things. I meant what I said with "I would *love* BGPSec to succeed" - no sarcasm or other meanings were intended. If BGPSec really is incrementally deployable then I have no objections to giving operators the means to create BGPSec certificates in the hosted system, and doing the same myself in Krill for that matter. Although I still believe it would then also be good - as I believe you hinted at as well - to hear if there are plans by router vendors to support this. Back to this point. I honestly want to understand it thoroughly. It is very well possible that I misunderstood or misremembered parts, but if so, ?I am not alone in this and it can help to ask the questions: A BGPSec certificate published in the RPKI can be valid or invalid. If it is valid, then the public router key can be used for BGPSec validation. Correct? Normal non-BGPSec updates are unsigned. They are neither BGPSec valid nor invalid, correct? A path can only be BGPSec evaluated of if it consists entirely of BGPSec updates, signed by each AS on the path. Broadly speaking the path is valid if all updates are valid, and otherwise it's invalid (section 5.2 of RFC8205). Correct? In principle therefore, operators can use local policy where they would reject a BGPSec *invalid* path, but accept unsigned paths. Correct? However.. I seem to remember it being brought up that this would allow malicious actors to do a downgrade attack where they simply remove the BGPSec signatures, resulting in a path that looks 'unsigned' rather than 'invalid'. Correct? My understanding of the incremental deployment considerations (section 7.9 of RFC 8205), rephrased by Job in his message, is that BGPSec validation can be mutually agreed on in islands. In other words, it's explicitly turned on. Correct? Question: would unsigned paths be acceptable? Other question: was it ever considered, and dismissed, to make the decision to use BGPSec validation automated? An approach that I can think of would be to assume that if, and only if, all ASNs on the path have published BGPSec certificates this can be read as a pledge that they will in fact do BGPSec. If so one could then also reject 'unsigned' here, and be safe against the downgrade attack. I don't know for a fact that this will work, but I am asking the question because I believe that automation will help. Manually deciding to turn this on on individual sessions will scale more painfully, let alone trying this cross transit. Kind regards, Tim > > randy

On 9 Oct 2021, at 11:13, Marco Marzetti <marco@lamehost.it> 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 then. But they might be now.The point is we don't know and we're discussing the topic starting from old pre-concepts or lack of knowledge.

My understanding is Job wants to change the status quo by having RIPE to "adopt" the technology. And I support that. Even though I acknowledge that some could find the presence of BGPSec on the same web portal as of RPKI confusing and that part has to be handled with care on the GUI. But, the overall effort seems small enough for RIPE to do it without consuming excessive resources (compared to RIPE's own capacity). So why not?

Why now? 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: 1. Publication Service I think this has immediate applicability to anyone considering running a delegated CA. It's also in the interest of the ecosystem to limit the excessive growth in the number of repositories. 2. ASPA This is in draft status, but so were ROAs when the production system launched in January 2011 (I should know, I was part of the RIPE NCC software team at the time, been reading and writing I-Ds and RFCs since 2009). 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 output with this information can already be valuable to operators, e.g. for provisioning. (This is also how ROAs were oftentimes used in the early days). 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 BGPSec in the hosted system would not be to test the protocol as such. This has already been done using Bird and Quagga and the RPKI tool set by Dragon Research Labs. It would really help to convince my idea of priority on this if at least a couple of router vendors would indicate that they are willing to listen to operator wishes here and implement. I hope this clarifies Tim

On Thu, Oct 7, 2021 at 12:17 PM Erik Bais <erik@bais.name> wrote: 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, might be a different rabbit hole .. ;-)

Back in 2008 we did some policy work here in the community for RPKI .. there were only a couple CLI based "validators", most routers vendors had no idea what RPKI was .. and still we asked the RIPE NCC to do work on RPKI. If you don't recall that, perhaps Alex B. can provide some history on that process __

What Job asked is to see if we should start with a similar process for BGPSec. We start with publishing and monitoring ... and who knows when and if this will become mainstream .. But if we don't start somewhere .. it will never get anywhere ..

The question and discussion isn't about if someone likes BGPSec or if it will ever become mainstream .. or if someone will personally ever use it .. or if the current status of the RFC's isn't finished yet to the final version .. In order to be able to asses this for the community .. there need to be some tools in place .. to make it easier for it to even go to that step. 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,

Regards, Erik Bais

On 07/10/2021, 11:41, "routing-wg on behalf of Tim Bruijnzeels" <routing-wg-bounces@ripe.net on behalf of tim@nlnetlabs.nl> wrote:

Hi Randy, all,

> On 6 Oct 2021, at 17:10, Randy Bush <randy@psg.com> 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 creative types could come up with something. please > color it magenta :) > > and, just as ROV has NotFound, BGPsec has not signed.

Please bear with me, it is not my intention to misrepresent things. I meant what I said with "I would *love* BGPSec to succeed" - no sarcasm or other meanings were intended.

If BGPSec really is incrementally deployable then I have no objections to giving operators the means to create BGPSec certificates in the hosted system, and doing the same myself in Krill for that matter. Although I still believe it would then also be good - as I believe you hinted at as well - to hear if there are plans by router vendors to support this.

Back to this point. I honestly want to understand it thoroughly. It is very well possible that I misunderstood or misremembered parts, but if so, ?I am not alone in this and it can help to ask the questions:

A BGPSec certificate published in the RPKI can be valid or invalid. If it is valid, then the public router key can be used for BGPSec validation. Correct?

Normal non-BGPSec updates are unsigned. They are neither BGPSec valid nor invalid, correct?

A path can only be BGPSec evaluated of if it consists entirely of BGPSec updates, signed by each AS on the path. Broadly speaking the path is valid if all updates are valid, and otherwise it's invalid (section 5.2 of RFC8205). Correct?

In principle therefore, operators can use local policy where they would reject a BGPSec *invalid* path, but accept unsigned paths. Correct?

However.. I seem to remember it being brought up that this would allow malicious actors to do a downgrade attack where they simply remove the BGPSec signatures, resulting in a path that looks 'unsigned' rather than 'invalid'. Correct?

My understanding of the incremental deployment considerations (section 7.9 of RFC 8205), rephrased by Job in his message, is that BGPSec validation can be mutually agreed on in islands. In other words, it's explicitly turned on. Correct? Question: would unsigned paths be acceptable?

Other question: was it ever considered, and dismissed, to make the decision to use BGPSec validation automated? An approach that I can think of would be to assume that if, and only if, all ASNs on the path have published BGPSec certificates this can be read as a pledge that they will in fact do BGPSec. If so one could then also reject 'unsigned' here, and be safe against the downgrade attack. I don't know for a fact that this will work, but I am asking the question because I believe that automation will help. Manually deciding to turn this on on individual sessions will scale more painfully, let alone trying this cross transit.

Kind regards, Tim

> > randy

-- Marco

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 implement both proposals, possible dependencies and other work. In order to implement BGPsec for hosted RPKI for example, we also need to keep in mind UI work on the RPKI Dashboard to make this easy to use (and easy to understand). Kind regards, Nathalie Trenaman RIPE NCC

Op 11 okt. 2021, om 12:36 heeft Job Snijders via routing-wg <routing-wg@ripe.net> het volgende geschreven:

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 it's more than we might think.

It is not clear to me what you mean with "more than we might think". I think a standard PKCS#10 / PKCS#7 exchange is less involved than implementing support for an entirely new Signed Object profile?

Additionally, to implement BGPsec support in the hosted environment, the developers can take inspiration from prior-art. For ASPA no examples exist yet.

...

In that context, I am not against BGPSec as such, there are just things that I would like to see first:

Thank you for sharing your personal wishlist. The above 'context' seems to depend on an assumption that work progresses sequentially.

...

1. Publication Service

I think this has immediate applicability to anyone considering running a delegated CA. It's also in the interest of the ecosystem to limit the excessive growth in the number of repositories.

2. ASPA

This is in draft status, but so were ROAs when the production system launched in January 2011.

I'll with the working group a brief overview of where ASPA is, which should help understand why ASPA probably is more of a 2022/2023 project. I'm personally involved as co-author of the ASPA specification.

* ASPA is 2 drafts, 0 RFCs: https://datatracker.ietf.org/doc/search/?name=aspa&activedrafts=on&rfcs=on This means that ASPA has not yet received review from the wider IETF community.

* As of yet no codepoints have been assigned to ASPA https://www.iana.org/assignments/rpki/rpki.xhtml

* No RPKI-to-Router protocol extension has been proposed for ASPA.

* At the IETF 111 SIDROPS meeting it was suggested to first construct a testbed before moving ASPA forward. See slids 11 and onwards: https://datatracker.ietf.org/meeting/111/materials/slides-111-sidrops-runnin... The testbed does not exist yet: https://github.com/SIDROPS/ASPA-testbed

* ASPA's running code status page still is empty https://trac.ietf.org/trac/sidrops/wiki ("AspaImplementations?" is a non-existing wiki page)

* Only a few months ago an issue was discovered in the ASPA verification algorithm in relationship to IX Route Servers. This has since been resolved (in -07 of the draft). To me it is an indicator that ASPA's specification still is in flux.

All in all ASPA undeniably is making progress, I would love for a RPKI-based routing policy signaling mechanism to exist, but there is a lot of work yet to be done.

I would suggest to start a discussion about adding ASPA to the RPKI Quarterly planning as soon as passed at least "IETF Working Group Last Call".

Kind regards,

Job

On 11 Oct 2021, at 12:45, Matthew Walster <matthew@walster.org> 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 I would like to see first." In any case, I know it's not my decision to make. Feedback was asked. I gave my 2cts

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:

1. Publication Service

I think this has immediate applicability to anyone considering running a delegated CA. It's also in the interest of the ecosystem to limit the excessive growth in the number of repositories.

as what the ncc would be 'selling' here is reliability, i suspect this would be part of a distributed deployment accenting reliability, maybe part of the cloudy thing. so it may take a while and be part of a project consuming a fair amount of resource, as you point out.

2. ASPA

This is in draft status, but so were ROAs when the production system launched in January 2011 (I should know, I was part of the RIPE NCC software team at the time, been reading and writing I-Ds and RFCs since 2009).

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 output with this information can already be valuable to operators, e.g. for provisioning. (This is also how ROAs were oftentimes used in the early days).

yup. and much more easily deployed than bgpsec. and small resource consumption by the ncc.

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 BGPSec in the hosted system would not be to test the protocol as such. This has already been done using Bird and Quagga and the RPKI tool set by Dragon Research Labs.

It would really help to convince my idea of priority on this if at least a couple of router vendors would indicate that they are willing to listen to operator wishes here and implement.

i know some vendors looking for phd student(s) or post-doc(s) to have a go at this. if you know of such, feel free to drop me a line. randy

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 and signing routers near the core. we're still trying to think about the bgpsec downgrade attack issue. some suggestions might need topologic declarations analogous to those of aspa. bgpsec needs a bit more work/study; and we're trying. aspa is closer to testable deployment if folk would stop rat-holing over useless corner cases. but, as i said in a previous, in the short term ncc resources might be better spent on reliable publication services. but unlike others, i do not pretend to understand the ncc's resources and/or planning. randy

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' state is something problematic that is lacking in BGPsec. The concepts and designs of both technologies are very different.

This means that if there is large scale issue with RPKI itself or your ability to validate RPKI data, BGPSec will end up saying your path is invalid. I think this is a rather scary property.

Indeed, BGPsec has a hard dependency on the RPKI being up and healthy. This is unavoidable consequence of the design decision to make one technology (BGPsec) dependent on another technology (the RPKI framework). The same of course applies to Route Origin Authorizations: if there is a large scale issue with the RPKI, one's ability to work with given RPKI data is impacted. I think the RIRs and NIRs are increasingly understanding that their RPKI services are expected to perform flawlessly. Great operational discipline is expected from Trust Anchors. (this applies to the TLS WebPKI too). At the end of the day, BGPsec (and RPKI) will not fancy everyone or be applicable for every possible situation, that's OK.

@2- incremental deployment is hard

BGPSec validation can only result in 'valid' if ALL ASNs on the path sign. Until that time the path will be 'invalid'. So BGPSec validation can only really be turned on after this point has been reached, and until this point has been reached there is no benefit and therefore no incentive to operators to buy BGP hardware that supports BGPSec, and publish their router keys as BGPSec certificates.

In practise the characteristic that you describe means that BGPsec deployment can happen incrementally on (for example) private peering between two companies. Indeed, not on 'full table transit' sessions. For example, in at large-scale cloud provider to cloud provider peering sessions, there often times are no downstream ASNs to be seen on either side. The traffic volumes are high, the number of routes on each side fairly low. As BGPsec-signed paths cannot traverse non-BGPsec topology, partial BGPsec deployment forms islands of assured paths. As islands grow to touch each other, they become larger islands. To do incremental deployment, both sides simply need to agree to use BGPsec, and not permit non-BGPsec sessions to establish at the particular intersection point. Keepin mind that a possible solution to prevent 'downgrade attacks', is to not tolerate downgrades... An analogy: I don't think anyone is expecting a BGP session to establish if there is a mismatch in TCP-MD5, TCP-AO, or IPsec configuration between two peers. The goal is for sessions NOT to establish if the password is wrong.

Because of the above I don't think that adding BGPSec support in the hosted interface will help. Don't get me wrong.. I would *love* for BGPSec to succeed.

I believe the path to success starts with actually making the technology available to increasingly larger groups of people. Literally making it "as hard as possible" to deploy BGPsec (aka, "maintaining the status quo"), will unsurprisingly lead to BGPsec 'not succeeding'. I don't know what the future holds and whether BGPsec will 'succeed', but I do know there is only one way to find out: making an honest effort to make it work. [ anecdote: I remember that in the early days of IPv6 it was quite hard to get IPv6 blocks in the RIPE region. To receive an IPv6 PI block, you had to be BGP multi-homed. This requirement did not exist for IPv4 PI space. Consequently, many people continued to request IPv4 PI blocks not spending any time on IPv6, because the RIR wouldn't give them IPv6 space to deploy. ]

I would like to be proven wrong in my interpretation. But as it stands I think a fundamental discussion is needed (in the IETF as well) on how it can be made incrementally deployable - such that there is benefit to early adopters - and get a safe landing in case of errors. If this can be achieved, or if someone can explain how this is already achieved, then I would be much less skeptical.

I don't know what your interpretation is based on, we clearly lack common experience and perspective on BGP routing. As for 'safe landing' (a nice sounding phrase), but in DNSsec there are no safe landings either. It is possible to productively use and operate systems in which the 'safe landing' would be to disable the system entirely. I recommend everyone to read https://datatracker.ietf.org/doc/html/rfc8374 and https://datatracker.ietf.org/doc/html/rfc8207 to get a feel for why some choices were made and what gotcha's exist. Kind regards, Job