[routing-wg] Add BGPsec support to Hosted RPKI?

> On 9 Oct 2021, at 11:13, Marco Marzetti <marco at 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 at 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 at ripe.net on behalf of tim at nlnetlabs.nl> wrote:
> 
>     Hi Randy, all,
> 
>     > On 6 Oct 2021, at 17:10, Randy Bush <randy at 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