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

Hi,

Please allow me to clarify my earlier comments.

On 12 Jun 2012, at 10:31, Tim Bruijnzeels wrote:

> Hi,
> 
> On 2 Jun 2012, at 01:00, Murphy, Sandra wrote:
>> The authors have stated that they believe that draft-ietf-sidr-pfx-validate-06 "BGP Prefix Origin Validation" is ready for a working group last call.
> 
> 
> 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..

> In particular I am worried about repositories:
> 1- being completely unreachable for a prolonged time
> 2- being inconsistent
> 
> 
> @1:
> 
> A relying party tool may choose to use old information if a repository can not be reached. This assumes that the RP has this old data, and it will only work for a while. There is some unclarity what to do if the manifest goes stale (next update time in the past) vs a manifest EE certificate expiring (http://tools.ietf.org/html/rfc6486#section-5.1 dictates a one-time use EE cert should match this).
> 
> In particular consider this case:
> 
> Parent CA:
> - has cert for 10/8
> - ROA for 10.0/16 AS A
> - signed cert to child for 10.0.0.0/22
> 
> Child CA:
> - publication point is unreachable, old data expired (new RP instances unaware even)
> 
> There is a very real possibility that the parent's ROA invalidates the child announcements.
> 
> I believe that the only reasonable, automated, action an RP can take in this case is to disregard any INRs mentioned on the child CA's cert whose pub point is unreachable.
> 
> 
> 
> @2:
> 
> With inconsistent I mean the following cases:
> - hash invalid for ROA
> - missing ROA
> - surplus ROA
> 
> The RP has a very tough time deciding what to do:
> - the invalid ROA could be a publication error, or it could be that another ROA with the same name was intended to be published, but we didn't see it
> - a missing ROA could validate an announcement that is now considered invalid because of another ROA
> - the surplus ROA's intention is unclear, it could be that the CA forgot to delete and revoke this, and it's invalidating announcement(s)
> 
> I understand that the authors intended manifests as a replay detection mechanism and most of the wording regarding validation uses SHOULDs and 'local policy'. However, I believe that this is not strong enough for pfx-validate. Local policy sounds very reasonable when in doubt, but I have no faith that operators will have enough knowledge to make educated decisions in all these cases. By and large I expect that operators will go with the *default* local policy decisions that are implemented in the RP tool they use.
> 
> In short I think that pfx-validate's requirement for full knowledge dictate that there MUST be a valid manifest listing the ROAs the CA intended to publish, they MUST all be present, all be valid, and no additional ROAs for the publication point can be considered.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr