Hi, On 29 Jun 2012, at 15:51, Randy Bush wrote:
>> With inconsistencies I did not mean that the validated cache is out of date, >> which I agree, will always be there even if it could be minimised. >> >> The inconsistencies I refer to are different in nature. It's that the >> snapshot that the RP tool got when it validated is in itself inconsistent: >> surplus or missing ROAs, or the hash of 1 or more ROAs doesn't match. Longer >> discussion omitted, but at this point the RP just doesn't know for certain >> what to do and guidance is needed. This is where *explicitly* stating a >> strong requirement, rather than leaving it implicit, in pfx-validate comes >> in.. > > would you like us to pull in the crucial paragraph from sec 6 of > origin-ops? > > Like the DNS, the global RPKI presents only a loosely consistent > view, depending on timing, updating, fetching, etc. Thus, one cache > or router may have different data about a particular prefix than > another cache or router. There is no 'fix' for this, it is the > nature of distributed data with distributed caches. > No, not exactly. I think it makes more sense to have this kind of guidance in an ops targeted document. Here I would just like to see it documented that the same kind of concerns raised with someone able to mess with the validated cache database (adding/removing records) apply to attacks or operational problems that happen before stuff goes into that database. Addressing this to the best of our abilities in operations and relevant standards is another discussion. One that I would like to save for another thread, and which does not have to block pfx-validate as far as I am concerned. Tim _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
