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

["Sriram, Kotikalapudi" <[e-mail]>]

>It appears that this guarantee will not always hold. Specifically, if
>two non-adjacent ASes conspire, and they are separated by a sequence of
>ASes that sign path data that they have not verified, then the
>conspiring ASes can violate the guarantee. 

Agree with that. 
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.

>I think this problem might be fixed if we modify the protocol to sign
>all of the preceding signed data (rather than just the immediate,
>previous signature).

If we agree that the above two-update collusion scenario 
is something we care about, then it should be noted that
this fix does not prevent it.

Sriram