[69835] in North American Network Operators' Group
Re: Xspedius / E.Spire as wellRe: Winstar says there is no TCP/BGP vulnerability
daemon@ATHENA.MIT.EDU (Richard A Steenbergen)
Tue Apr 20 18:18:36 2004
Date: Tue, 20 Apr 2004 17:48:29 -0400
From: Richard A Steenbergen <ras@e-gerbil.net>
To: " John Brown (CV)" <jmbrown@chagresventures.com>
Cc: Rodney Joffe <rjoffe@centergate.com>, NANOG <nanog@merit.edu>
In-Reply-To: <20040420153030.A58863@alderaan.chagres.net>
Errors-To: owner-nanog-outgoing@merit.edu
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 !@#$%^&*. 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 <ras@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
