If I understand David¹s attack vector correct than the attack would look as follows:
For the path ‹ > A ‹> B ‹> C ‹> D ‹> E with A and D conspiring and B and C only signing but not validating: A signs the path to D and not to B but sends it to B. Because B and C don¹t validate, just sign they forward the path to D. D removed B and C from the path and forwards the path as ‹> A ‹> D to E. Now E verifies the path as valid and moves on. If this is what David had in mind then I agree that the security guarantee in 7.1 does not hold up. Oliver On 8/27/15, 1:58 PM, "sidr on behalf of Rob Austein" <[email protected] on behalf of [email protected]> wrote: >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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
