Subject: header and data digest issue

From: "Bob Mastors" <[email-masked]>
Date: Wed, 27 Feb 2002 09:48:58 -0700

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

---

From: "John Hufferd" <[email-masked]>
Date: Wed, 27 Feb 2002 09:40:54 -0800

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: [email-masked]

"Bob Mastors" <[email-masked]>@ece.cmu.edu on 02/27/2002
08:48:58 AM

Sent by:    [email-masked]

To:    "IPS" <[email-masked]>
cc:
Subject:    header and data digest issue

For example:

Bob

---

From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <[email-masked]>
Date: Wed, 27 Feb 2002 11:38:17 -0700

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:[email-masked]]
|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: [email-masked]
|
|
|"Bob Mastors" <[email-masked]>@ece.cmu.edu on 02/27/2002
|08:48:58 AM
|
|Sent by:    [email-masked]
|
|
|To:    "IPS" <[email-masked]>
|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
|
|
|
|