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

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