Re: [Sidrops] [routing-wg] misconceptions about ROV

[Tim Bruijnzeels <[e-mail]>]

> On 23 Feb 2022, at 13:27, Randy Bush <[e-mail]> wrote:
> 
>> Am I correct though that if BGPSec *Path* validation were to be
>> applied to unsigned paths they would be considered 'Not Valid'?
> 
> no.  not validatable, if you wish.  not valid is a result of
> validating the signature chain.  as one can not do that with
> a non-bgpsec path, it can be neither valid or not valid.
> 
>> And isn't this what the downgrade issue (for which I cannot
>> find a ref now) is about? Rather than violating signatures, the
>> signatures can just be stripped.
> 
> the downgrade attack is a router accepting a bgpsec path and
> producing a bgp4 path toward the 'victim'.  in a more likely
> operational scenario, the router simply refuses bgpsec from its
> incoming peer, so that peer sends it bgp4 which it then sends on
> to the 'victim'.  though that make a louder signal of the attack.
> 
>> Meaning that even if you would call such a path 'not signed',
>> rather than 'not valid' accepting those paths would mean that
>> 'not valid' can be easily avoided by adversaries.
> 
> yes
> 
>> Hence, I believe, the idea to only accept BGPSec *path* 'Valid'
>> on BGPSec "islands".
> 
> no.  routers on those islands still need to reach non-bgpsec
> destinations and even bgpsec speaking destinations on other
> islands.  this means they must also accept unsigned paths.

Yes, of course.

What I meant here by "accept... on islands" is that the operator
would have to know - somehow - where to enable BGPSec validation.

I believe that the idea was that this would be done on a BGP
session basis. E.g. providers would insist on BGPSec from customers,
or peers between each other etc.

> 
>> Is there a way that these "islands" can be recognised
>> automatically, and cross transit (i.e. include unknown
>> parties)?
> 
> you could tunnel between islands; but that is operationally
> unlikely.  i remember uucp :)
> 
> and you can not take an unsigned path and start signing.  to what
> are you attesting?

That is not what I was trying to suggest.

I wondered if (new) signed statements in the RPKI could be used to
conclude that ASNs have pledged to use BGP Sec when possible. I.e.
such ASNs would sign a path if they are the origin / or if the receive
a signed path.

The receiving router could then conclude that IFF all ASNs in a path
had made these signed statements - BGPSec validation on *that* path
could be performed. It would be an error if signatures were missing
or invalid.

This way operators would not have to enable this manually on a per
session basis, and because it would be based on signed validated
statements they could trust that it would be safe to apply for ASNs who
issued those statements - without the need to know these ASNs first
hand - e.g. across transit.

It would still allow for path spoofing and signature removal by
injecting an ASN that did not sign a statement that they would
do BGPSec. However, the options would become more limited as more
ASNs participate - and ASPA validation would further limit the available
choices.

As for how an ASN could sign such a statement.. one could overload
existing router certificates but I think that is probably a bad
idea - it could very well lead to timing issues when adopting. An
alternative could be to have a new separate signed object for this,
which would allow that BGPSec is tested first, before letting the world
know.

Just an idea.. hoping it might help.

Tim






> 
> randy