Re: [Sidrops] 6486bis: Failed Fetches

> On 4 Sep 2020, at 22:40, Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
> 
> Hi,
> 
>> On 2 Sep 2020, at 20:33, Jay Borkenhagen <jayb@braeburn.org> 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.
> 
> 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.

This should have said: overlap with the intersection of resources on those ROAs and the CA certificate.

> 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.
> 
> Tim
> 
> 
>> 
>>> Experience with X.509 cert extensions suggests that the approach I noted 
>>> is preferable. Saying that older RPs can ignore objects they don't 
>>> understand introduces ambiguity in RP behavior, which is precisely the 
>>> concern that motivated the effort to generate 6486bis.
>> 
>> Ambiguity is bad in any technical endeavor where precision is needed.
>> And we're here discussing this now because there was ambiguity in
>> rfc6486 (not assigning blame -- I missed it, too).  But I don't see
>> how it follows that if/when ASPA (for example) is standardized, that
>> older RPs should be required to throw away all records retrieved from
>> PPs whose MFTs now cite ASPA records.
>> 
>> Thanks.
>> 
>> 						Jay B.
>> 
>> 
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops