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. 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
