[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Replacement for BGP-TCP-MD5
On 18 jan 2008, at 4:07, Markus Stenberg wrote:
TCP MD5 protects the links between routers. It does nothing at all,
de nada, zero, zip, about protecting what the routers
say.
Actually, it does protect what they say, it just doesn't make what
they say right.
(What's more, it is cryptographically unsophisticated and outmoded.)
Yes.. This is what I was trying to point out, with a broken example.
Anyway, even with the admittedly broken key handling (static manual
keying),
We had an IETF meeting where we roamed from session to session talking
about this. This is actually a fairly difficult problem to really
solve: if you want to be able to change keys, you need agreement
between both sides, and reaching this agreement out of band is the
problem. (If you have that then TCP MD5 is not a problem today except
perhaps for the timing of the change.) Reaching this agreement in band
is fairly non-trivial because then you need something that's long term
stable that you can derive the more ephemeral keys from. Which has to
be something that you can verify without connectivity to avoid
circular dependencies.
broken protocol (replay attacks and such)
Good luck replaying TCP...
and partially broken digest algorithm, it seems to be still working
well enough. I haven't heard about any attacks against the BGP+TCP-
MD5 really happening out there in the wild.
The biggest problem is that it has no DoS protection, so basically you
protect against the risk of spoofed TCP RSTs at the cost of assuming
the risk of your route processor CPU be drowned in MD5 calculations.
In theory, MD5 is light weight and many packets can be rejected
without doing the MD5 calculation, but in practice route processors
slow down significantly in the presence of MD5 digests.
However, I find it rather disturbing that the TCP folks are now
apparently looking at this. IPsec was made for this type of stuff: it
is extensible, has strong algorithms, an anti-replay counter that
helps against CPU exhaustion attacks for off-path attackers (if
there's an attacker on the link between two routers you have bigger
problems), supports negotiating new session keys and it's widely
implemented. Solving the same problem a third time is at best a waste
of time.
However, the problem with IPsec is that vendors have made their
implementations extremely complex to configure, so even though the
crypto people say set up and forget for TCP MD5 is really, really bad,
the operators don't care because they don't see actual attacks, so
they're not willing to spend the time and effort to deploy BGP over
IPsec.
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg