Re: [sidr] WGLC for draft-ietf-sidr-pfx-validate-06

[Tim Bruijnzeels <[e-mail]>]

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