Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

["Sriram, Kotikalapudi" <[e-mail]>]

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