my memory is that seq num guessing and sending rst was the core problem motivating tcp/md5 for bgp, and btsh came some years later. but no big deal. i think that, indeed, md5 keys are shared across many links *within* an op's infrastructure. but, since integrity, and not privacy, is the goal, this does not seem risky. carrying keys to new networks seems a bit risky as does re-use with multiple external parties.
given the existance of effective mitigations for the ibgp case, I've need seen a reason to employ it internally or to explore support for rfc 4808 mechnisms since key rolling is effectively an external coordination problem.
if i need to roll keys on ibgp, i suspect i have a far more serious problem than if it is ebgp, twice as serious at a minimum :) < rathole > i am not much worried about a mesh which floods unicast. can you even buy devices which support that any more? a while back, i had to really dig in the closet to find one at 100mbps so i could shark mid-stream.
I have thousands of establish connections that last a very long time at public exchange points, so the threat of tcp rsts to sessions is clearly not being realized.
my theory is that, as the attacks were mitigated the attackers moved on to other things. after all, the non-nuisance benefit i get by resetting your bgp session with margaret is shifting your traffic past some place i can mitm or to a more expensive, to you, link. the attackers moved on to more lucrative endeavors. randy