SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: header and data digest issue




    David,

    Usually (not always) middleboxes terminate TCP connections. That is the reason some of us wanted a separate CRC on the data - even with IPsec.  The scenario suggested is not the only way in which middleboxes may mess up things.  An incrementaly recomputed  CRC may solve this type of failure but who says that the middle box will play by the rules and not mess-up with the data in unexpected ways?  I think that we have a decent solution for SCSI data integrity that is both simple and robust with respect to accidental failures.

    Julo


    Black_David@emc.com
    Sent by: owner-ips@ece.cmu.edu

    27-02-02 21:47

           
            To:        bmastors@aciesnetworks.com, ips@ece.cmu.edu
            cc:        
            Subject:        RE: header and data digest issue

           


    > I think there is a problem with the current design of the
    > header and data digest.
    > There is a non-zero chance that an error could cause
    > the target to process a single pdu that has a header from
    > one pdu and data from a second pdu.
    >
    > This type of error is undetectable by the target with the CRC32C
    > digests turned on.
    >
    > For example:
    >         Initiator sends pdu 1 which contains header H1 and data D1
    >         Initiator sends pdu 2 which contains header H2 and data D2
    >         Target receives pdu 1 which contains header H1 and data D1
    >         Target receives pdu 2 which contains header H2 and data D1 (bad)
    > In this example the header and data digests will checksum correctly.
    > However the wrong data will be written to addresses indicated in H2.
    >
    > There are three obvious places this error can occur:
    >         1. the initiator
    >         2. an intelligent router/switch
    >         3. the target
    >
    > Not much can be done about initiator problems.
    > But I would like to detect problems introduced by the other areas.

    The middlebox problem is inherent in allowing middlebox functionality
    which was the rationale for using separate CRCs.  One can stop a middlebox
    from making this mistake by running IPsec ESP's keyed cryptographic
    integrity
    check end-to-end - if some middlebox tries to get clever, the ESP integrity
    check fails and the packets that make up the corrupted PDU are dropped; if
    the middlebox error is persistent, the TCP connection will probably close.
    Changing the CRC check won't stop middleboxes - if some CRC gets in the way,
    the middlebox will strip the offending CRC and regenerate it - the result
    is *still* vulnerable to implementation bugs in the middlebox (and cleverer
    things like putting the data digest in the header or vice versa are
    vulnerable to similarly cleverer implementation bugs).

    > I think it is actually likely that my target software will run
    > in an environment that produces this type of error.
    > Imagining how an intelligent router/switch or off-board iSCSI target
    > hardware might operate, it is probably only a single bit logic error
    > that could cause this type of error.

    If "intelligent" means the router/switch is iSCSI-aware, ESP cryptographic
    integrity is the right means to protect against modifications - anything
    less (especially omitting the keying) is an invitation to the "strip the
    CRC and regenerate" scenario akin to the one in the middlebox paragraph
    above.

    If an iSCSI target is off-board, it has stripped, parsed, and discarded
    the iSCSI header - no CRC of any form will protect against a bug in that
    target that got confused about which data went with which header.  Protocol
    implementations remove headers from data and have to keep track of what
    they're doing - there's no free lunch here (e.g., if a CRC covering header
    and data is added, an implementation will likely to check that and strip it,
    after which it can still get confused.

    > Maybe it is not appropriate to address this problem in the iSCSI spec
    > because I have described a problem that would not occur on the wire.
    > However iSCSI is the mechanism that allows more hardware and software
    > to be interposed between the SCSI initiator and the SCSI target.
    > iSCSI should not allow a single bit logic error in this additional
    > hardware and software to produce an undetectable error.

    The only problem scenario I see involves middleboxes, and iSCSI
    provides a tool (IPsec ESP cryptographic integrity) that addresses
    that problem.  Did I miss anything?

    Thanks,
    --David

    ---------------------------------------------------
    David L. Black, Senior Technologist

    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
    black_david@emc.com         Cell: +1 (978) 394-7754
    ---------------------------------------------------




Home

Last updated: Thu Feb 28 19:18:10 2002
8947 messages in chronological order