[Sidrops] Indeed, we are not done yet (Was: [routing-wg] misconceptions about ROV)

[Job Snijders <[e-mail]>]

Hello all,

On Tue, Feb 22, 2022 at 09:41:36AM +0100, Tim Bruijnzeels wrote:
> Which is why I think it would be very good to re-double the WG efforts
> on moving ASPA forward.

It probably bears repeating: ASPA and BGPsec are complementary
technologies. Each attempts to solve a different problem space. There is
no overlap.

> It was also suggested in the past few months that BGPSec should get
> a new impulse by supporting it in the RIPE NCC hosted RPKI:
> https://www.ripe.net/ripe/mail/archives/routing-wg/2021-September/004410.html
> 
> My responses in that thread were a bit skeptical to the point of being
> misunderstood as obstruction to the idea. I am not against BGPSec itself.
> Far from it. I just want to believe that it can work.

At times it is easy to mistake someone's skepticism for a message of
Fear, Uncertainty, and Doubt. Especially when considering the finality
of such discussions: would you be the one implementing BGPsec in the
RIPE NCC RPKI dashboard? Are you the one configuring routers to use
BGPsec? Is your personal belief in BGPsec a necessity for the global
deployment of BGPsec?

> My issue was about how BGPSec can be implemented incrementally and
> scale *automatically*. I know of the idea that operators turn it on
> (and off?) because they somehow know (out-of-band?) that it's safe to
> do so. But, (1) I don't see this scale, (2) this can result in outages
> if operators get it wrong (path invalid), and (3) I don't see this
> work cross-transit - which is probably where the problem of spoofed
> origin attacks is worse.

Are you speaking from your own experience deploying BGP security
measures in IP networks, operating the BGP side of an ISP/IXP/CDN?
Phrased differently: is it really important for you to understand how
exactly something scales, if you aren't personally (or as organization)
scaling & deploying a given technology? What is it to you whether BGPsec
is "scalable" or not? How does one even define "scale", what metrics are
used to judge feasibility or value?

For example, has it been contemplated whether BGPsec offers benefits
when deployed at 'small' scale? ('small scale' for example being
third-party CDN caches embedded inside ISP networks which use BGP). I
share Randy Bush's perspective on this matter:
https://mailman.nanog.org/pipermail/nanog/2021-December/217003.html

Another point worth mentioning: many people consider "Internet
Consolidation" [0] to be a detrimental evolution, however there is a
silver lining, an aspect that can be used to the collective's advantage:
because of consolidation, fewer market players need to take action to
positively impact the Internet experience of the masses [1].

> In my view, this comes from the property that BGPSec validated paths
> can only be valid or invalid. There is no 'unknown' - because in a
> nutshell then adversaries could do a simple downgrade attack.

I'd encourage everyone to use more precise wording: The phrase 'unknown'
does not appear in RFC 6811, there is "Not Found". "Not Found" is the
DFZ's starting state, because when the Internet was created there were
no RPKI ROAs. Thus it must be like that - because how else would one
accomplish incrementally deployability for ROV? :-)

If one zooms in, the notion of 'Not Found' as a third state really is a
complicated one: the cryptographic verification process for ROA EE
certificates only has two outcomes: valid or invalid. The origin
validation of BGP routes covered by one or more ROAs only has two
outcomes: valid or invalid. I view the polarity of the outcome of the
BGPsec's verification process in a similar fashion.

> All that said, if we could have a constructive discussion about
> solving the BGPSec deployment challenges then I would welcome it very
> much. Perhaps, it would be possible to signal (with signed objects in
> the RPKI) when BGPSec is applicable - and when a downgrade has
> happened.. somehow? No, I don't have the answer but we may want to put
> our minds together.

I'd like to encourage you (and others) to first focus on implementing
rudimentary support for BGPsec Router Keys "according to current RFCs",
rather than leaping towards defining new signed objects. The definition
of new objects should be informed by operational experience, perhaps
summarized in a gap analysis.

I think that at this stage working towards gathering real world
operational experience is a prerequisite before extending the BGPsec
protocol specifications in one direction or another. Horse before cart
so to speak. :-)

Regards,

Job

[0]: https://datatracker.ietf.org/doc/html/draft-arkko-iab-internet-consolidation
[1]: slide 9 https://storage.googleapis.com/site-media-prod/meetings/NANOG84/2488/20220214_Madory_Measuring_Rpki_Rov_v1.pdf