Date: Mon, 14 Jun 1999 14:29:54 -0400
From: Craig Metz <cmetz@INNER.NET>
To: BUGTRAQ@netspace.org
Subject: TCP MD5 option problem

  I was implementing the RFC 2385 ("Protection of BGP Sessions via the TCP MD5
Signature Option") option in the OpenBSD stack. For those who don't know the
significance of this option, it is used to provide some level of active attack
(primarily hijacking) protection for BGP sessions on Internet core routers. One
thing I noticed about the spec is that TCP options are completely excluded from
the MAC function.

  The IOS TCP implementation doesn't appear to do anything significant with
TCP options and does not send any, and so, therefore, this doesn't seem to be
a problem on those systems. However, there are several other players in the
core router space (e.g., Juniper and Torrent/Ericsson) who use 4.4BSD-derived
operating systems, and those have networking stacks which DO use TCP options.
In particular, 4.4BSD processes the TCP MSS, timestamp, and window size
options, and includes enough padding that one might also be able to shuffle
things around and slip something else in.

  A possible active attack might be to sniff a TCP packet in transit and to
spoof a version of that same packet with the TCP options changed, in hopes that
the genuine packet will be dropped in transit but the spoofed one will get
through. A quick read of the BSD source indicates that a MSS option's size of
zero will be internalized, which might be one possible attack to try. Such an
attack might be able to adjust TCP parameters to "choke" the TCP connection;
it will be alive and connected, but little to no routing data would move. That
in turn could be used either as a denial of service attack or to partition
groups of routers to make other attacks harder to detect.

  I haven't cooked up a real exploit for this because I don't have any of the
routers that would be affected handy in my lab, but I suppose that someone so
inclined could do so given this discussion and some time to experiment.

  The (IMO) obvious fix for this problem is to use IPsec's Authentication
Header (AH) and to deprecate the TCP MD5 option. There are several freely
available and viable AH implementations for BSD (including the NRL, OpenBSD,
and KAME ones) and I believe that modern IOS has AH code in it though it's not
currently set up for protecting routing traffic. AH covers all of the TCP
header and options, as well as typically having a better MAC function (the RFC
2385 option builds a MAC by appending the key, which is possibly the weakest
way to do it).

                                                                        -Craig

-----------------------------------------------------------------------------------

Date: Wed, 16 Jun 1999 22:33:36 -0400
From: Steven M. Bellovin <smb@RESEARCH.ATT.COM>
To: BUGTRAQ@netspace.org
Subject: Re: TCP MD5 option problem

In message <199906141822.SAA05311@inner.net>, Craig Metz writes:

>
>   The (IMO) obvious fix for this problem is to use IPsec's Authentication
> Header (AH) and to deprecate the TCP MD5 option. There are several freely
> available and viable AH implementations for BSD (including the NRL, OpenBSD,
> and KAME ones) and I believe that modern IOS has AH code in it though it's not
> currently set up for protecting routing traffic. AH covers all of the TCP
> header and options, as well as typically having a better MAC function (the RFC
> 2385 option builds a MAC by appending the key, which is possibly the weakest
> way to do it).

The RFC 2385 scheme describes a hack that was developed precisely because
IPSEC wasn't ready, and *something* was needed to protect BGP traffic.
You're absolutely right -- no one should use it for any new work.