Re: Winstar says there is no TCP/BGP vulnerability

["Christopher L. Morrow" <christopher.morrow () mci com>]

On Wed, 21 Apr 2004, Robert E. Seastrom wrote:

> "Christopher L. Morrow" <christopher.morrow () mci com> writes:
>
> > there is the issue of changing the keys during operations without
> > impacting the network, eh? Having to bounce every bgp session in your
> > network can be pretty darned painful... if you change the key(s) of
> > course. If you don't you might as well not have keys, since adding the
> > 3 lines of C code required to Paul Watsons' program making it do
> > the hashing certainly won't be a big deal, eh?
>
> I've added keys without bouncing the sessions...  doesn't seem to
> cause any difficulties at all.  You just add the password clause on
> both ends within the window for a BGP keepalive timeout.  Worst case,
> this line:

yup, this is the expected behaviour at a certain level of code... I don't
recall that level but I'm sure a cisco person could give us the rundown :)
Basically, as I understand the explanation given to me, there is no
defined manner to deal with:
1) changing keys
2) adding keys
3) removing keys

in the RFC for this (2385). So, atleast Cisco, implemented key change in a
sane manner, if you change the key packets immediately start heading out with
the new key used as the hash key. The far side starts logging 'bad key'
messages but the session doesn't reset and updates keep attempting to be
sent, until you either change the key, or the session timeouts hit.

For adding keys, I have experienced the following:
Apr 21 17:01:45.278: %BGP-5-ADJCHANGE: neighbor <ip> Down -
Password change

on 12.0S and 12.1(19)(non-s) code trains...

on passwd change:

Apr 21 17:03:36.117 GMT: %BGP-5-ADJCHANGE: neighbor <ip> Down
Password change

So, this is obviously suboptimal. The good news is code releases up the
chain seem to have this fixed, getting there is a chore, but will make MD5
more operationally managable in the long term, and thus more widely
deployed, eh? (hopefully)