tcp.md5.router.dos.txt

`Date: Mon, 14 Jun 1999 14:29:54 -0400  
From: Craig Metz <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
Subject: Re: TCP MD5 option problem  
  
In message <[email protected]>, 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.  
  
`