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

[Rob Austein <[e-mail]>]

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.