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

Hi,

> On 22 Feb 2022, at 11:47, Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
> 
> On Tue, Feb 22, 2022 at 10:19:23AM +0100, Tim Bruijnzeels wrote:
>>> On 22 Feb 2022, at 09:51, Di Ma <madi@juicybun.cn> wrote:
>>> It seems to be a good idea to do signaling and have a sort of signed
>>> object for policy indicator :-)
>> 
>> I think we need a model where we can have valid/invalid/not-found (or
>> equivalent) for paths.
> 
> Do we really? Slide 10 "BGPsec is protocol, not policy":
> https://archive.nanog.org/meetings/nanog52/presentations/Tuesday/Bush-bgpsec.pdf

I did not say it's policy. I don't know what would be needed. But it
would help if people had an automated way to know that BGPSec validation
can be applied or not for a given path / session etc.

> 
>> Then we people can turn validation on with much less risk, and people
>> can start implementing BGPSec on their routers independently with more
>> immediate (albeit initially small) benefit.
> 
> I am not so sure about the above, it seems the reasoning stems from a
> desire to seek compromise without regard for the consequences of such
> settlement. The notion of "less risk" needs to be quantified more
> precisely to have meaning.
> 
> I understand the goal of BGPsec deployment to be to reject
> BGPsec-invalid paths, that's all. If the signatures are trash: don't
> accept it, I don't see 'middleground'.
> 
> Are there any scenarios in which one would want to accept BGPsec invalid
> paths? Similarly, RP implementations discard malformed ROAs, network
> operators reject RPKI ROV-invalid BGP updates.

Currently you need to accept BGPSec invalid path on any path where
at least one ASN does NOT participate in BGPSec. Applying BGPSec path
validation is only safe when you know that ALL ASNs on the path
participate.

> If people perceive risk: don't enable BGPsec, let others be the early
> adaptors. It is early days, lots of software still has to be written,
> lots of testing is required.

What I am hoping for, essentially, is that a partial deployment model
would be more feasible where people are not expected to form islands,
which merge, without specifying how those islands form or merge.

If there would be a 'not-found' like state for the *path* validation,
and reliable way to clearly detect an *invalid* path as opposed to
a path with non BGPSec capable ASNs, then a simple reject *invalid*
policy could be applied.

I understand this is not trivial. If it were, it most likely would
have been solved before 2011. Still, it may be useful to think about
this again.

Reject invalid && partial deployment has worked well for ROV. And,
time will tell, but I strongly believe it will work well for ASPA.
I would like something like this to work for BGPSec.

Alternatively - rather than having a 'not-found' it may be an option
to automate a safe decision on accepting only 'valid'. See below.

> 
>> Note that all this is orthogonal to ASPA. ASPA essentially says
>> whether paths are plausible, and BGPSec (valid path) says what
>> actually happened.
> 
> Yes, the above is an accurate summary.
> 
>> Though if ASPA informs that an adjacency is invalid then this could
>> perhaps be valuable input to BGPSec path validation with regards to
>> downgrade detection.
> 
> Only time and research can tell whether it is a useful signal to
> transfer from one plane to another plane.

The two are orthogonal, but may complement each other very well.

Suppose, for the sake of argument, that routers would know (through
validation) that all ASNs on a path are certain to participate in
BGPSec then they could also 'safely' reject any such BGP invalid
paths. If this decision can be automated then operators don't need
to create or destroy the islands manually.

Adversaries could still spoof paths, but if the ASPA 'AS_PATH' is
then invalid - they would presumably be rejected on that basis.

If the ASPA 'AS_PATH' would be valid and accepted, then the addition
of BGPSec validation on that path (provided the ASNs are known to
participate) would give additional security.

As I said I don't know.. I am just trying to look at it from another
angle.

> 
> Regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops