Re: tcp/ip hardware offload

From: Ron DuFresne (dufresneat_private)
Date: Wed Feb 27 2002 - 18:35:47 PST

  • Next message: Craig Knox: "Re: BUG: [Kernel 2.4.18 - IP Tables 1.2.4] ?"

    Richard,
    
    The closest discussion I've seen from time to time related to this, and
    again recently on the firewalls list has been the hp printer cards and
    their poor handling of simple variances in TCP params that send the
    printers they are installed in into failure modes requireing a full
    recycle.  The results of simple nmap scans are known to either fully
    freeze up the printers or send them into garbage page spewing moeds, yet
    they all require a recycle to correct.  Course, I have seen no mention of
    new hp direct cards with corrected firmware released over the years, and
    this is an old known issue.  Perhaps the code to be used in the devices
    you mention is going to be much more stable, but, you make a good point in
    that it's possible that future exploits might well make such devices
    expensive door-stops of the future.  Hopefully the design folks are
    throughly testing the stacks and exercising them to discover their
    potential limit prior to production and marketing...
    
    Thanks,
    
    Ron DuFresne
    
    
    On Tue, 26 Feb 2002, Richard Masoner wrote:
    
    > I'd like to bring up for discussion a topic I don't think I've seen before
    > -- that of possible vulnerabilities in networking code in hardware
    > devices.  Specifically, several vendors are developing network adapters
    > with full TCP/IP offload in the hardware.  These aren't just cards with a
    > network stack in firmware; a lot of these actually have the protocol
    > implemented in silicon.
    >
    > iReady <http://www.iready.com> is selling the "iChip," which is targeted
    > for lower-end, embedded applications.  Adaptec and Intel have announced
    > gigabit network adapters with full protocol offload.  Driving these
    > products is the burgeoning market for network storage (iSCSI in
    > particular), and the fact that OS protocol handling can gobble up over half
    > of CPU cycles just to process the incoming network packets.  If you offload
    > protocol handling, you free the CPU for other tasks.  From a performance
    > perspective, it makes perfect sense.
    >
    > I'll write to these companies for additional details (and hope for a
    > response), but my guess is that the protocol is implemented in some sort of
    > programmable logic on an ASIC, and that these adapters will not be
    > in-circuit upgradeable.
    >
    > The risk I see is the discovery of a vulnerability in these hard-wired
    > "protocol accelerators."  What if a malformed packet could throw these
    > adapters into an undefined state?  In a software TCP/IP stack, you just
    > patch the operating system and life goes on.   What do you do with hardware
    > that's discovered to be vulnerable to DoS attacks?
    >
    > Is there a history of hardware being vulnerable to online DoS attacks like
    > this?  Has anyone discussed this already?
    >
    > Regards,
    >
    > Richard Masoner
    >
    
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    "Cutting the space budget really restores my faith in humanity.  It
    eliminates dreams, goals, and ideals and lets us get straight to the
    business of hate, debauchery, and self-annihilation." -- Johnny Hart
    	***testing, only testing, and damn good at it too!***
    
    OK, so you're a Ph.D.  Just don't touch anything.
    



    This archive was generated by hypermail 2b30 : Mon Mar 04 2002 - 16:52:44 PST