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

[Job Snijders <[e-mail]>]

Hello Tim, others,

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

"In order to indicate that a BGP speaker is willing to send BGPsec
 UPDATE messages (for a particular address family), a BGP speaker
 sends the BGPsec capability"
 source: https://datatracker.ietf.org/doc/html/rfc8205#section-2.2

Indeed, it is an operator choice whether to enable BGPsec or not, and it
is choosen per-session. Luckily most large operators have automated the
provisioning of BGP sessions.

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

I am not sure it is helpful at this stage.

It seems you overlook some deployment aspects, for example: within a
given Autonomous System (during the incremental deployment of BGPsec -
which may take years) there will be ASBRs that support BGPsec and ASBRs
that are unable to negotiate support for BGPsec. For example, it is
entirely possible that at a given moment in time only half the
adjacencies for 206238_15562$ are BGPsec capable, and half are not (yet). 

See this posting for a similar story on RPKI ROV invalids:
https://mailman.nanog.org/pipermail/nanog/2021-April/213346.html

Frankly speaking, wouldn't it make far more sense to implement the
specifications AS SPECIFIED AND PEER-REVIEWED BY MANY PEOPLE,
*before* advocating new object profiles?

Especially since the CA side of BGPsec is so straight-forward and
simple to implement ... ?

Regards,

Job

ps. Since you asked, here are required reading materials:

BGPsec Protocol Specification
	https://datatracker.ietf.org/doc/html/rfc8205

BGPsec Considerations for Autonomous System (AS) Migration
	https://datatracker.ietf.org/doc/html/rfc8206

BGPsec Operational Considerations
	https://datatracker.ietf.org/doc/html/rfc8207

BGPsec Algorithms, Key Formats, and Signature Formats
	https://datatracker.ietf.org/doc/html/rfc8208

BGPsec Design Choices and Summary of Supporting Discussions
	https://datatracker.ietf.org/doc/html/rfc8374

Router Keying for BGPsec
	https://datatracker.ietf.org/doc/html/rfc8635