>> 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. > >Without replay protection, I don't see how this recommendation would >help. I.e., the old signed update would still be valid. >
In the example with -- > A --> B --> C --> D -->, if B and C (the ones that were signing but not verifying) return to the update to verify, then they will realize that the update they last signed (for the prefix) was invalid, and will propagate an alternate valid signed announcement or send a withdrawal message to D. At this point, B and C have taken their corrective action. Their well-behaving neighbors (others besides D) will act on the new valid announcement or the withdrawal. But if D is still malicious and suppresses the new valid announcement or the withdraw, then that would be a classic withdraw suppression / replay attack. (B and C are not contributing to collusion anymore at this point.) And the solution at that point is whatever remedy draft-ietf-sidr-bgpsec-rollover-04 offers. Sriram _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
