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

[Job Snijders <[e-mail]>]

On Thu, Feb 24, 2022 at 10:16:39AM +0100, Tim Bruijnzeels wrote:
> > 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).
>
> Not at all - any adjacencies that are not BGPSec capable would not issue
> any statement that they are capable. So stripping the signatures there
> would be entirely expected.
>
> I am talking about something else: signalling deployment beyond direct
> sessions in order to enable detection of downgrade attacks. If router
> can detect that the *entire* path is not only capable but also
> committed to do BGPSec then removal of signatures can be flagged as an
> attack.

At the risk of repeating myself: signalling at AS-level granularity
seems too coarse for deployment reality. An AS might be able to do
BGPsec in one part of their network, but not in other parts of their
network. Another consideration: not all Autonomous Systems operate with
a coherent backbone, some AS are "islands".

Imagine AS 65000, 65001, and 65002, who all have half their ASBR
footprint BGPsec enabled; neither of those 3 AS can 'commit' to BGPsec;
other than through per-BGP-session negotation. BGPsec islands connect to
each other by virtue of unbroken valid signature chains.


> > 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 ... ?
>
> There is no need to shout Job..
>
> I was trying to have a discussion about a possible way to help
> operational future deployment.

I appreciate all the help you are willing to provide, but I question the
soundness of initiating discussion about 'future deployment' while the
first steps have yet to be set on the path towards deployment. How can
anyone meaningfully comment on future operational deployment challenges
without any operational experience with BGPsec "as is"?

> This is in no way preventing the development and deployment of current
> standards. And should the idea be useful and accepted then of course
> it would be handled as a WG document, be peer-reviewed etc.
>
> I know - it's naive to think that that would be what the IETF
> is for. Fine. I will stop here. Discussion once again seems
> entirely pointless.

At times it seems you look to this WG for help, other times you purport
opinion on what the future direction of RPKI / Secure Routing should be,
and then other times you appear to engage in research/brainstorm
activities. It is hard to tell which is which at times.

The current discussion might appear challenging because your positions
appear inconsistent: first you expressed heavy skepticism to the point
that it might even discourage others to consider BGPsec ("it doesnt
scale"), then you pivot to suggesting new object profiles, all the while
writing messages which contain imprecise terminology.

Here you ask for pointers:
https://mailarchive.ietf.org/arch/msg/sidrops/shD2HMkgDrXSf7dLI6GAkOuaoKg/
Here you reply you could find the documents yourself:
https://mailarchive.ietf.org/arch/msg/sidrops/DcbDU25miO0Rcc9Hbd85kaDvDx0/

Here you ask whether there is 'operator demand':
https://mailarchive.ietf.org/arch/msg/sidrops/XOHyvcRKH6VOG310jAUppzRXliA/
But already back in October 2021, you yourself noted: "Wrt BGPSec.. I am
actually very happy to see that so many people are in favor of supporting
it.":
https://www.ripe.net/ripe/mail/archives/routing-wg/2021-October/004454.html

It seems to me that one could extrapolate appetite for BGPsec in managed
CA environments to mean that people also would like BGPsec support in
all other CA implementations.

Let's make BGPsec a reality! It all starts by actually making BGPsec
available to operators.

Regards,

Job