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