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

[Tim Bruijnzeels <[e-mail]>]

> On 22 Feb 2022, at 20:13, Geoff Huston <[e-mail]> wrote:
> 
> 
>>> 
>>> 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.
> 
> 
> I can’t parse these two sentences Tim. They seem to contradict each other
> when I read em. The AS signing chain is stripped as soon as an update leaves the
> original BGPSEC “island”. I thought that an AS can’t just restart the signing chain
> subsequently.

Let me try to be more clear then. I am not trying to suggest the signing
chain is restarted.

BGPSec path validation procedure results in one of two states: 'Valid' and
'Not Valid'. (section 5.1 of 8205).

A BGPSec path as a whole can only be 'Valid' if all signatures are present,
and they are all valid.

The absence of any signature, whether it's because the update left a
capable island, or an adversary removed signatures, results in 'Not Valid'.

Rejecting 'Not Valid' is therefore only safe on known islands.

Outside of these islands all paths are BGPSec 'Not Valid'. Therefore
validation cannot be enabled outside of known islands. You would accept
'Not Valid' outside of islands, even though you are not checking that state
in that context. Sorry if that was cryptic.


>>> 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.
> 
> This desire seems rather inexplicable to me, in that if one allows routes where
> the AS signing chain is broken then it could be broken becuase of
> tampering or other malicious acts as much as they are broken for more
> benign reasons. How would the BGP speaker receiving the route tell the 
> difference? And if it can’t, then it seems to me that there is no point in
> adding this additional workload to update processing if in fact it is
> incapable of detecting tampered AS Paths.

Although I used the terms 'not found' and 'unknown' somewhat loosely
elsewhere I did not mean to say that broken chains should be acceptable.

One take on this could be that routers can know whether a path consists
of only "participating" ASNs and then treat it as an "island" automatically
without the need to be manually enabled. Such automation could allow
operators to opt-in to validation for parties that they don't have a direct
relationship with - e.g. cross transit.

If the "island" decision can be automated then stripping of signatures
on them could be interpreted as malicious.

This limits path spoofing option to non-participating ASNs. This will
be harder to do as more ASNs participate in BGPSec *and* ASPA validation
(if deployed) will further limit the adjacency options. This also enables
ASNs to protect themselves in two (orthogonal) ways - giving them
immediate benefits to deploy.

Of course the above could only ever work if the router can know that
an ASN "participates". The presence of a router certificate for the
ASN could give a clue - but I am not sure that it is enough. Is creating
such a router certificate a valid pledge? If it is, then that means
much less standards work would be needed.

If it isn't then a separate signed statement by the ASN that they
will do BGPSec whenever they get a signed path could help. This could
be done using a new RPKI signed object type, or by way of an extension
in the existing BGPSec router certificate perhaps. But this would also
require a new RPKI-RTR version as well.


Tim


> 
> Geoff
> 
> 
>