Re: [Sidrops] 6486bis: Failed Fetches

[Stephen Kent <[e-mail]>]

Tim,
> Hi,
>
>> On 2 Sep 2020, at 20:33, Jay Borkenhagen <[e-mail]> wrote:
>>
>> Steve,
>>
>> Stephen Kent writes:
>>> The crux of the issue is whether it is preferable to reject all objects
>>> at a pub point if an error is detected (until the error is rectified),
>>> and thus potentially treat many more routes as having an unknown
>>> verification status, or to accept bits and pieces of data from a pub
>>> point with the potential that some routes will be treated as valid, even
>>> if they are invalid. To me, that is a value judgement to be made by
>>> network operators, not by developers of RP software. [...]
>> No, there is a bit more to it than that.
>>
>> I want my network's routers and those of all other networks to be fed
>> with VRPs that represent all the verified and legitimate published
>> origin-ASN intentions of verified, legitimate IP number resource
>> holders.
>>
>> Clearly the challenge there is in determining "verified" and
>> "legitimate."  In creating the rules (to be documented in
>> standards-track RFCs) for those determinations, I would like the input
>> of all SIDROPS participants to be valued, including the input of the
>> RPKI designers, the CA- and RP-implementers, the RIRs, and the network
>> operators.
>>
>> To my point: if RP-implementers feel that the "bits and pieces of
>> data" (to use your words) should be considered to best make those
>> determinations, such input should be welcomed; conversely, if
>> RP-implementers feel that strict publication rules and accompanying
>> strict handling of retrieved records together create the best way to
>> make those determinations, we all should listen to what they have to
>> say.
> I don't think it's entirely fair to say that us 'developers' are willing to create security issues for network operators.
>
> This document is still under discussion, and there simply are still cases that are not fully discussed, e.g. how to filter VRPs if a publication point is found to be bad - to which I posted a suggestion only last week. I thought that discussion phases were meant for that. To look at things from different angles. I am quite certain though that consensus can be reached if we have constructive talks, and that implementation can follow quickly when it does.
Sure.
> To the point of "bits and pieces". Rejecting a full publication point is the easiest to reason about, so I can see its appeal. That said, consider the case where a ROA is invalid because it contains a prefix no longer held by the CA. Instead of rejecting the complete PP for a CA certificate, and filtering out all VRPs overlapping the resources on it, one could also reject all the invalid ROAs and only filter out VRPs that have any overlap with those ROAs. I understand this is a bit more elaborate, but not dramatically different. As far as I can tell it is just as secure in that this cannot result in RPKI invalid announcements because of a single invalid ROA object.
>
> Note that I talk about ROA objects that can be fetched, and are known to be current. I.e. the actual manifest content. And provided they can be parsed and validated so you know which resources are affected. If any objects are missing or obsolete then assume the worst - I actually made statements to that effect months ago.
>
> In any case, I can live with the reject-all model for its simplicity. But I would like to hear an operator input on whether this is indeed desirable. And that the consequence of child CAs - even NIR sized ones - blinking out for a few hours every now and then is an acceptable price for this simplicity.

In revising 6486 I iterated through several versions, and received 
feedback that the less strict versions were not consistent with the 
perceived) WG consensus. That's how we arrived at the current version of 
the document. Simplicity is certainly a virtue wrt security, so more 
"elaborate" approaches to RP processing of repository data do concern 
me. Also, if a lot of RP software is having a hard time implementing the 
current set of validation procedures correctly, adding more complexity 
seems like a bad idea.

Steve