Winstar says there is no TCP/BGP vulnerability

David Luyer david at luyer.net
Wed Apr 21 08:15:56 UTC 2004


Michael,

> > David Luyer wrote:
> > Have done around 100 of these in the past 24 hours. It's
> > not related to platform AFAIK - we've successfully done
> > the changes on a lowly 2651 and 3620 without outages, but
> > a 7200 with older IOS did have an outage.
> 
> Given the context, I assume that you have added MD5 to sessions that did
> not have it previously, I am correct?
> Then, do you mean by "without outages" that the session was not reset by
> the password add/change? If I may ask, how many out of 100 did not
> reset?

98 of the first 100 did not reset.  Today, I did another 12 and only one
failed.

The 2 to fail were one with 12.2(17a) and 12.2(23) where we got the timing
a couple of seconds off -- not sure if the reason was IOS or timing -- and 
one with a 12.0S release where the reset is automatic.  Testing also
revealed that 12.1 had an automatic reset, just we didn't run into it in
production.  The one which failed today was another case of 12.0S.

However some providers run 12.0S exclusively so I'd expect they'd see
every single session reset.  And when it comes to Juniper/Foundry/Extreme,
I haven't set up passwords on any of the sessions to these vendors yet.

The important thing is the IOS - as I stated earlier, it's easy to test
in a lab and see if the router syslogs a reset on putting in a password,
if it doesn't syslog one then you have a very strong chance it won't
reset, but if it's a critical BGP session it would still be sensible to
do it in an off-peak window (which happens to be why I haven't done any
of the BGP sessions to peers using Juniper/Foundry/Extreme yet).

If you have a fully redundant internal BGP, and are running all
12.2S/12.3/12.2T, then you can rather safely do the internal BGP
passwords without a customer notice, expecting no session drop but
knowing if one did you'd have routes via a second BGP reflector anyway.

One note - when you do this, the table version shown in 'show ip bgp sum'
resets to zero in some IOS versions.  This appears cosmetic; routing is
not impacted and this can also occur when simply putting a description
against a BGP peer.

David.




More information about the NANOG mailing list