Doug and I have discussed the issues raised in this thread in some detail. We feel that the following considerations (with corresponding changes in the document) would help resolve the issue(s) we are dealing with:
1. As mentioned already, signature should cover more data so that the collusion vulnerability that David pointed out can be addressed. 2. It was a conscious design decision to not require (MUST) validation before path selection and signing in all cases. Lazy (or deferred) evaluation (e.g., the ability to select and sign a path before validation) adds performance / robustness options to implementations that address real operational concerns (e.g., convergence time on table dumps, bootstrap, etc.) that were identified early in the BGPsec design process. 3. In consideration of the above (#2), the document should instead strongly recommend that “if an AS signs an update without verifying first, it SHOULD return to the update at its earliest and verify, and forward a new signed update, if necessary." Make this a strong BCP recommendation. 4. If this recommendation (#3) is followed, then other collusion/replay effects that have been identified on the list will be short lived (e.g. Oliver’s: http://www.ietf.org/mail-archive/web/sidr/current/msg07248.html ). Adverse effects would be short lived, if the duration of deferment of verification (if any) is short. Sriram _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
