>
>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.
>
It appears you agree that the two-update collusion scenario that
I described is feasible. It is basically another mechanism by which the
colluders seem to achieve the same effect as in David's collusion scenario.
(I think so, but I'm open to being proven wrong about that.)
The latter, it appears, can be mitigated by signing 'all of the preceding
signed data', but not the former (two-update collusion).
Both scenarios or threats rely on intermediate ASes not verifying.
So both of these scenarios are mitigated by requiring intermediate
ASes to verify. This is the observation I would like to make.
Since you made contrary comments, let me point out respectfully
that replay attack mitigation is in the requirements (RFC 7353):
4.3 Replay of BGP UPDATE messages need not be completely prevented,
but a BGPsec design SHOULD provide a mechanism to control the
window of exposure to replay attacks.
And there is an active SIDR WG draft dealing with replay attack mitigation:
https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-04#section-4.2
However, a solution for the specific collusion threat we are discussing
does not benefit at all from replay attack mitigation techniques.
All that D is doing (in my example) is to hold the first update for 15 or 30
seconds.
The bgpsec-rollover draft proposes router key rollovers,
but (thank goodness) not on that small/tiny (seconds) time scale!
Sriram
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
