I noticed Outlook changed some characters so here again:
If I understand Davids 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 do not 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, 3:15 PM, "sidr on behalf of Borchert, Oliver" <[email protected] on behalf of [email protected]> wrote: >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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
