TCP MD5 option problem

From: Craig Metz (cmetzat_private)
Date: Mon Jun 14 1999 - 11:29:54 PDT

  • Next message: pedwardat_private: "Re: Weird ps behavior"

      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
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:49:42 PDT