Date: Mon, 14 Jun 1999 14:29:54 -0400 From: Craig Metz 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 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.