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



    
    
    I have to agree with Bob Mastors that there is a non-negligible probability
    for such a mixup in an intelligent router such as an iSCSI middlebox. A
    middle box that touches the iSCSI PDU could, it seems to me, cause the mixup
    that Bob describes with relative ease.
    
    Suppose an iSCSI middle box buffers iSCSI PDUs and, for its convenience,
    delineates the header from the data sections with some scheme such as
    storing iscsi headers and data sections (or pointers to them) in separate
    buffers. The iSCSI middle box then does some manipulations to the headers
    and eventually rejoins header and data prior to forwarding the PDU.
    
    I can envision several types of single logical errors causing an incorrect
    matchup of header and data. Suppose the pointers to the data and header
    sections of the iSCSI PDU are stored in circular queues. A circular Queue
    failure that causes the same entry to be read twice or an entry to get lost
    could cause the type of mismatch that Bob Masters alludes to. Similarly a
    single bit change in a pointer could also cause the mismatch.
    
    Software errors in the middle box could of course cause the same mismatch.
    
    Of course the middle box could also have internal redundancy in order to
    catch such errors but this is beyond the control of the Initiator and
    Target.
    
    It seems to me that, by splitting header and data digests, we lost the
    automatic protection that a single CRC would have provided against such
    mixups. 
    
    Of course I have to admit that even one CRC accross the entire iSCSI PDU
    does not guarantee that middle boxes cannot easily corrupt the iSCSI PDU in
    ways that the end nodes cannot detect. For example a middle box could make
    some intentional changes to the iSCSI PDU that is protected by a single CRC
    and also make some unintentional changes. It would then recompute the single
    CRC. 
    
    This last problem could be solved if the middle box would simply "adjust"
    the CRC for the intentional changes - the unintentional changes would then
    cause a CRC error at the recipient - but it is my understanding that this is
    considered difficult to do or there would have been no need to split the
    digest in the first place.
    
    What other means are there for the ends to identify such a mismatch?
    
    Vince
    
    
    |-----Original Message-----
    |From: John Hufferd [mailto:hufferd@us.ibm.com]
    |Sent: Wednesday, February 27, 2002 9:41 AM
    |To: Bob Mastors
    |Cc: IPS
    |Subject: Re: header and data digest issue
    |
    |
    |
    |I do not believe a single bit error could cause what you 
    |suggested.  The
    |data is a stream of TCP bytes.  TCP does not know the difference. Also
    |these are not separate packets, there is no reason to think 
    |that there is
    |any more probability of an error occurring at that DataSection boundary
    |then any other place in the stream.
    |
    |To say that somehow, this same error caused a completely different Data
    |section to have a like problem at its Data Section boundary, 
    |and that they
    |would now get crossed at exactly that point, tells me it is a 
    |SW error, not
    |a single bit error.
    |
    |.
    |.
    |.
    |John L. Hufferd
    |Senior Technical Staff Member (STSM)
    |IBM/SSG San Jose Ca
    |Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    |Home Office (408) 997-6136, Cell: (408) 499-9702
    |Internet address: hufferd@us.ibm.com
    |
    |
    |"Bob Mastors" <bmastors@aciesnetworks.com>@ece.cmu.edu on 02/27/2002
    |08:48:58 AM
    |
    |Sent by:    owner-ips@ece.cmu.edu
    |
    |
    |To:    "IPS" <ips@ece.cmu.edu>
    |cc:
    |Subject:    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.
    |
    |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.
    |
    |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.
    |
    |Bob
    |
    |
    |
    |
    


Home

Last updated: Wed Feb 27 15:18:07 2002
8911 messages in chronological order