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

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

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