|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Xspedius / E.Spire as wellRe: Winstar says there is no TCP/BGP vulnerability
On Tue, Apr 20, 2004 at 03:30:30PM -0600, John Brown (CV) wrote: > > Seems Xspedius aka E.SPire aka ACSI doesn't feel that MD5 is > important on their BGP sessions either. > > Based on the ticket we filed last week, Managment does not > feel its warranted to make these changes. > > On the other hand, SPRINT was willing and able to take MD5 > session info right away. WAY TO GO SPRINT. While somehow I doubt that the likes of E.Spire and Winstar are doing it because they know it is the correct thing to do, in actual fact they are right. All the whining about how we all should have deployed MD5 years ago proves one very important point, it hasn't been deployed widely because it is a ROYAL PAIN IN THE [email protected]#$%^&*. I haven't actually run the tests myself, but people who have are telling me that the implementations of TCP-MD5 on the major vendors do not take steps to check the sequence numbers (in the case of a rst) or wait for a syn|ack in the syn cookie/cache/whatever implementation (in the case of a syn) before doing the cpu burning MD5 hash. So congratulations, we all just made our routers trivially easy to bring down with even a minor SYN/RST flood and an MD5 key included in the packet, even an invalid one. Knee jerk security reactions don't always work out in your favor. :) BTW if someone wanted to actually implement this in a way which made sense, besides taking the opportunity to implement the checks I mentioned above before doing MD5 processing... I think the best way to go here is a public key authentication mechanism. Peers could post their public key on their peering websites or easily exchange the information in clear text offline, the other side could then install it on their devices when they turn up the peers, and it would then be used to automatically exchange MD5 keying information. Obviously you don't want this happening every time, but it would be easy enough to cache this data after an initial key exchange and authentication check, and only fall back to the public key exchange following a reboot (if you dont store keys in something other than ram) or following an MD5 key mismatch for whatever reason. -- Richard A Steenbergen <[email protected]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
|