On 16 Jun 2012, at 22:59, Pradosh Mohapatra wrote: > Hi Tim, > > >>> Prefix validate assumes full knowledge of all applicable ROAs (or other >>> sources of information if they are used) and I believe this should be >>> stated more strongly. >>> >>> The security considerations section addresses the possibility of a >>> malicious attacker tampering with the database that is used for validation. >>> It does not address the possibility of a database becoming incomplete for >>> other reasons. >> >> This is the main point I wanted to make. I believe this can be easily >> addressed by just stating the requirement in this document. Perhaps >> something along these lines at the end of the first paragraph in the >> security consideration section: >> >> "Additional or missing records resulting from retrieval and/or validation >> errors can lead to the same problems." >> >> The following was just a discussion on how RPs can mitigate these problems. >> But.. perhaps this is better addressed in a separate BCP, or future work on >> specifications related to the repository and retrieval/validation by RPs. >> >> If the WG can agree with this then I can support last call.. > > > I do not agree this is a "security" issue. I am guessing you meant > permanent/eventual inconsistencies between the local and global repositories > (since transient inconsistencies will always be there). That kind of > inconsistency is most certainly a (protocol) implementation error and has to > be dealt with at that layer. >
I see your point about security, I don't really mind which section addresses this. 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.. Having this will help to either come up with best practices for RP tools, or preferably improvements to the repository related standards. Anyway, I get the feeling that I am the only one here who sees this as a problem, so I guess the rough consensus is there.. Tim _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
