Re: [Sidrops] 6486bis: Failed Fetches

[Stephen Kent <[e-mail]>]

Martin,
> ...
>>> "not update anymore" is not how I would state the result. This fetch
>>> will fail. Because a failed fetch will be reported to the RP
>>> operations staff, hopefully they will contact the cognizant entity
>>> for the pub point in question, causing the error to be fixed. Them a
>>> subsequent fetch can succeed.
>> That seems like an overly optimistic approach to the issue. Assume the
>> problem is created by a bug or, worse, design oversight in the CA
>> software. The turnaround from discovering the issue to deploying a fix
>> can easily be weeks with some vendors. During all that time, not only
>> can no ROAs be updated and may child CA certificates slowly expire, the
>> entire CA’s data will not be available at all for any newly deployed
>> relying parties. With containerised deployment, this is quite a serious
>> issue.
>>
>> As a consequence, this approach will make the routing system less
>> secure for, I’d like to argue, no actual gain.

When I the WG chairs tell me that I misunderstood the WG consensus re 
strict correctness then I will revisit this topic. However, the recent 
messages from Mikael and Job suggest that your perception of WG 
consensus is not accurate. This issue is one that needs to be decided by 
network operators, not by developers of RP software. I agree with the 
observations made by Mikael and Job, i.e., that requiring strict 
conformance with manifest rules is the preferred approach.


>>>> You could argue “Don’t do that, then” but this approach doesn’t make
>>>> the RPKI more robust but rather makes it break more easily on simple
>>>> oversights.
>>> My sense of the WG discussion was that the majority of  folks chose
>>> to prioritize correctness over robustness, and I made numerous
>>> changes to the text to reflect that.
>> I disagree with the blanket assessment that this approach makes RPKI more
>> correct. To switch to the example I should have used in the first place:
>> Ignoring a broken GBR object when producing a list of VRPs does not
>> make the list less correct. In fact, the opposite is true: Ignoring the
>> CA or updates to the CA because of a broken GBR makes this list less
>> correct.

I suspect we disagree on what constitutes "correct." A correctly 
functioning CA does not publish objects with bad signatures or format 
errors, use certs that have expired, does not fail to replace expired or 
stale objects, does not include objects at pub points that are not on 
the manifest, etc.

>
>>> ...
>> You absolutely have to deal with this issue in 6486bis in its current
>> strict form. Any introduction of a new object type will permanently
>> break CAs that use these objects when validated with a relying party
>> software that is not aware of this type. I don’t think this is
>> acceptable, as it effectively blocks the introduction of new types
>> pretty much forever.

No, it does not. What I suggested is that when a new object is proposed, 
it is the responsibility of the those proposing the new object to 
explain how it will be incrementally deployed. That explanation belongs 
in the RFC defining the new object, and in an updated version of 6486 
will need to be generated. We have no good examples of new objects that 
provide a basis for describing how to accommodate incremental 
deployment, and thus no basis for defining such mechanisms at this time. 
It might be the case that a new object will be defined that requires the 
CA to maintain a separate pub point using some newly-defined SIA 
pointer, indicting that the new pub point contains the new object and 
thus RPs that don't know how to process the object MUST NOT follow that 
pointer. There will need to be agreement on how long a CA MUST maintain 
the old pub point, etc. But, absent a concrete example of a new object 
type that warrants this sort of effort it is premature to write a spec.


>>> Instead I believe it
>>> makes sense for any new object proposed for inclusion in the RPKI
>>> repository system to address this question as part of its
>>> documentation; it's not clear that a uniform approach is appropriate,
>>> i.e., one size may not fit all. 6486 can be updated to reflect the
>>> processing approach proposed for any new objects.
>> It seems to me that the best approach is to simply ignore unknown
>> objects. We could argue whether they can be ignored completely or
>> whether one should at least check their manifest hash. Personally, I
>> think completely ignoring is the better approach as I don’t see any
>> benefit in rejecting a CA because someone swapped out an object I don’t
>> care about.
>
>
In X.509 certs we mark extensions as critical, or not. An extension 
marked as critical will cause a cert to be rejected by an RP that does 
not know how to process that extension. One might revise the generic 
signed object definition (RFC 6488)  introduce a similar flag. But, 
first, we would have to figure out how to incrementally deploy the new 
signed object format, with a new version number, etc. I hope you see why 
this approach to incremental deployment of new object types probably 
would entail more that a revision of 6486.


>> Ultimately, I feel we’ve swung the pendulum way too far to the other
>> side. The RPKI isn’t a single data set that needs to synchronized in
>> full but it consists of multiple data sets that can be treated as
>> independent: currently these are VRPs, router keys, and GBRs. If I use
>> the RPKI for route origin validation, I don’t need to synchronize the
>> router keys or GBRs. Why does it improve route origin validation if
>> available and correctly signed data is skipped because of issues with
>> irrelevant data?

The RPKI was designed to support origin validation first, and BGPsec 
second. The set of objects that were defined are intended to support 
these two functions. If the WG decides to extend the set of supported 
functions it needs to take a hard look at a wide range of RFCs that will 
be affected, not just 6486.

Steve