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

["Borchert, Oliver" <[e-mail]>]

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"
<[e-mail] on behalf of [e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/sidr