At Thu, 27 Aug 2015 15:45:49 +0000, Sriram, Kotikalapudi wrote: > > What do you think of the following two-update collusion scenario? > -- > A --> B --> C --> D --> E > A and D are colluding. B and C are signing without verifying. > First update at time= t0: > A signs and forwards an update normally (without any corruption). > The update propagates via B and C to D. > D receives it and stores it, but does not forward to E (or anyone). > Second update at time= t1 (= t0 + delta): > A sends an intentionally corrupted version of the update (signed), > while keeping the same NLRI as before. > B and C are still signing but not verifying. > The update propagates via B and C to D. Now D replaces > this corrupted update with the earlier clean one (received at t0), > and propagates to E. The resulting update from D to E is valid. > One can argue that there is violation of the guarantee (in Section 7.1) > at time t1. The valid route propagated from D to E does not > agree with the route that B or C forwarded (at time t1) > for the NLRI in consideration.
If I understand your scenario correctly, as far as folks further along the path are concerned, this is a replay attack by D. That D is doing this to cover up something bad that A is doing to B and C is almost irrelevant, as is the specific nature of whatever bad thing A is doing to B and C. So, yeah, OK, it's a form of collusion, but it's not one that relies on a weakness in the signature semantics, it's one that relies on lack of protection against replay attacks, something the WG discussed and rejected. Can't speak for anybody else, but I'm not particularly interested in exhuming the replay horse at this late date. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
