Re: [Sidrops] 6486bis: Failed Fetches

[Tim Bruijnzeels <[e-mail]>]

Hi

> On 5 Sep 2020, at 20:08, Stephen Kent <[e-mail]> wrote:
> 
> Tim,
>> ...
>> In short: Given that I expect that we are never come to a consensus other than the total reject-all-if-one-fails - I can live with this if we must, but don't let it come as a surprise.
> Works for me.
>>> ...
>>> Allowing RPs to ignore object types they don't understand prevents a CA from being able to convey the notion that a new object type is important (to that CA). I don't think this is a good strategy. It means that RP behavior will be ambiguous relative to new object types.
>> So far none of the objects have seemed to need this flag.
> If the goal is to define a very general scheme, then a flag may be necessary to accommodate objects not yet defined, since we cannot yet know whether a uniform response for all such objects will be appropriate. I agree that this need not be a binary flag, as in cert extensions. You suggested a three-value flag below, for example.
>> ...
>>> If we want to have a consistent and flexible approach to accommodating new objects I suggest the strategy I mentioned earlier. Define an additional SIA URI that points to a pub point (and manifest) where we can introduce the next version of the signed object format, one that includes a critical flag, analogous to X.509v3 extensions. This allows each CA to decide which object types have to be processed  by an RP in order for the whole pub point to be accepted vs. rejected. Note that this will require modifying a lot of RFCs, but it is a flexible, extensible approach to this issue.
>> I agree that it's flexible and extensible. I had not thought of this approach.
>> 
>> But it is a lot of work, not just in RFCs, also in code. It also raises questions about how and when old PPs without the new objects can be deprecated. You can give operators more time to upgrade, but at some point plugs will probably be pulled? Maintaining multiple PPs indefinitely seems rather wasteful.
>> 
>> I would like to hear what others have to say.. I have the feeling that ASPA is getting close, and I would really not like to see it delayed because of this.
> It will take a while to complete another revision of the manifest doc, if we purse additional changes, and even longer before an RFC is approved and published. So ASPA will not be accommodated quickly. Also, as I noted in my reply to jay, a quick read of the ASPA doc didn't indicate how these new objects are validated using the RPKI.

https://tools.ietf.org/html/draft-ietf-sidrops-aspa-profile-02#section-4

The text is still a bit short, and can probably use some feedback, but I believe that the direction is clear. Informally: It's an RPKI signed object, that contains a "customer" ASN which MUST be in the EE certificate. The EE certificate MUST of course be valid.

In my perception ASPA is quite close to testing (no not in the production repositories of course).

>> If we do go down this road then I think that we should also look at the manifest object itself, and let it convey which object (types) are critical (and while we are at it, we can specify types instead of using filename extensions). That way future object types could introduced more easily perhaps - this obviously needs more discussion but it could even allow for semantics like: 1) new object please test, don't use, 2) new objects, use if you can, 3) new objects, critical - fail if you don't understand.
> 
> One could combine the new SIA URI and a revised manifest, in which the manifest contains the per-object flag, rather than redefining the basic object format to accommodate the flag. That would reduce the number of RFCs that need to change. Good idea.

Upon reflection I realised that even the introduction of an SIA in the issuing CA certificate will lead to issues. RPs would reject the CA certificate, and as a result the whole PP of the parent CA. This means that the SIA cannot be deployed without leaving a significant number of RP installations behind. E.g. if I run a delegated CA under an RIR which wants to adopt ASPA, and I get a new CA certificate with the additional SIA from my parent, then 1000s (RIPE NCC >12k) other CAs will also be rejected.

So the only option then is to wait for a significant number of updated RP tools to be available, and then at some point take the plunge and let CAs deploy - and tell operators who suddenly find that their VRP count drops to near zero that they should (have) upgrade(d).

This poses a serious problem to future RFCs - I just don't see how they can achieve an incremental deployment that does not result in the issues above.

I understand your desire to keep 6486bis focused - and I sympathise. However, I do believe that it needs to specify some plan. Perhaps an SIA can be reserved? Perhaps it can be published in conjunction with ASPA - timelines permitting - postponing the pain? Perhaps just checking the presence and hashes for unknown object types, but not validating them can be reconsidered? (I heard your objections, just listing it again in this context)

I am quite open to other suggestions. But, if there can be no plan that facilitates future RFC deployments, then I believe that at the very least the document should include a section that discusses this issue (perhaps security considerations, or a separate section altogether).

> Your example bothers me a bit- it seems to argue for CA-directed processing flags, perhaps to accommodate experimentation with new object types. This sounds like adopting elements of the IRR DB model which didn't seem to be so great, IMHO.

Not where I meant to go, but this can be a future discussion.

Tim


> 
> Separately, I think we need to make GBR mandatory for all pub points. If the intent is to cause RPs to contact a CA/pub point maintainer when errors are encountered, then we need to be confident that RPs know who to contact and how.
> 
> Steve