Re: [Sidrops] [WGLC] draft-ietf-sidrops-roa-considerations-01 - Ends 10/March/2022

[Tim Bruijnzeels <[e-mail]>]

Dear WG

Allow me to share some thoughts outside of the box.. the things below
may not work but I believe they are worth thinking about.

> On 10 Mar 2022, at 21:46, Stephen Kent <stephen.kent=[e-mail]> wrote:
> 
> Geoff,
>> 
>> agreed, yet we have TLS using just-in-time credential provisioning in the
>> initial handshake which has very different scaling properties. The models
>> of DNSSEC provisioning also staple the credentials to the data. RPKI
>> is one of the few models that attempt to pre-provision the entirety of the
>> credential sets to all relying parties all of the time, and I find myself
>> wondering why we ever thought that such an approach would scale!
>> 
>> yes, I agree its just one more aspect of the intrinsic brokenness of the
>> Internet, and, as you say, we plod on! :-)
> 
> TLS creates a pairwise connection between two entities, so transmitting the cert of the server is an obvious, simple approach to solve the problem in question. And, because of the artificially shallow PKI underlying the issuance of certs to servers (thanks to the browser vendors and the cabal of for-profit CAs), it's easy to ensure that a client gets the certs (and CRLs) it needs.
> 
> The RPKI requires essentially ALL RPs to have access to the certs for essentially ALL address space holders. It is much more logical to have a bulk distribution mechanism to facilitate this, vs. some sort of pairwise distribution mechanism of the sorts you cite. The requirements for cert and CRL distribution are completely different for the RPKI vs. the Web PKI- apples vs. kumquats (as Randy might say).

I believe there may be merit in *combining* current repositories with information
that may be sent in BGP itself.

There are some issues with relying on the current RPKI repositories that may benefit
from this approach.

- Delays

New announcements may be invalid regarding to current ROAs, similarly a new provider
may be invalid under known ASPA providers (when deployed), and a new BGPSec router key
may be unknown.

RPKI objects will have to published, retrieved, validated and the validated content
(VRP, providers, ASN-router-key) have to make their way into routers. Until that time
announcements and routes may be rejected.

The delay can be significant. Optimistically it can be as low as 20 minutes between
a CA publishing a new object and on-path routers getting the validated content, but
it may take much longer as well - more than an hour would not be uncommon.

- Repository unreachable

Consider that an RPKI Repository becomes unreachable because for example a mistake
was made in ROA configuration - and this ROAs is published in said repository..

Obviously this should be avoided, but if it does happen then recovery is painful.

RPs are not going to be able to retreive any updated corrective ROA, until the old
information expires and ROV goes to "not found" rather than "invalid". Slurm may
help a bit but I don't think that expecting all ASNs to start using exceptions would
be realistic.

For BGPSec things may be worse - suppose the old router key is lost and unusable..
The repository could publish a new BGPSec router key, but its route would be invalid,
so RPs in validating networks would not be able to find out.

- Publishing CA (client) unreachable

In this case a delegated CA has invalidated the prefix for their CA software and
is no longer able to reach the repository server.

Again this should be avoided, but if it happens..

If the CA can use an alternative path or Slurm between itself and the repository
server then this may help to fix things. Alternatively it can wait for manifests
and CRLs to expire. Or it can ask the parent to be revoked.

I would say all of these are painful.

- Include objects in BGP

Suppose that in some future we would not do full TLS but allow routers to send
the necessary authorization objects for the context of their announcement/update
along. This could simply be the applicable ROA object, ASPA object of BGPSec
router certificate. Dedicated objects could be invented if needed - but there
may be no need.

Routers that receive such objects for routes lacking a current VRP/ASPA/router
key entry could then dispatch this (rtr++) to RP software which can then validate
these objects directly under the applicable CA certificate that it has. Much
like Job was describing for RSC objects. Routers that already have received
the entries through rtr (or lack this capability of finding the objects in BGP)
can ignore the included objects.

In other words: it would allow capable routers to discover new attestations
sooner, but it would not require any or all routers to do this.

This would of course require that routers have a way to include necessary
object. There could be APIs that allow operators push relevant objects manually,
but one could even consider an RTR like protocol where routers can talk to a
CA to get objects. ROAs/ASPAs/BGPSec certificates are usually long-lived,
so this exchange would be low volume and infrequent.

A slightly more involved approach would be to CMS objects with a full path
of certificates and CRLs. But.. this would require regular updates of all
those - and make the validation process more involved. So, just expecting
objects that are signed directly under a known CA certificate (which btw
could also revoke these objects if needed) would still be complicated, but
much simpler.

I understand that all of this would add complexity to an already complicated
infrastructure. So, not doing any of this may be a valid answer, but.. I
don't see other obvious ways to deal the situations described above. If
anyone has other ideas about ways to handle them I would be very interested.



Tim










> 
> Steve
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops