RE: iscsi: header digest issue

["Douglas Otis" <dotis@sanlight.net>]

Paul,

One future solution could be SCTP-DDP and an IANA registration for SCSI.
Data transfers in the DDP_WITH_TAG mode where Placement Tag matches the CDB
tag.  The SCSI CDBs and responses use the ANONYMOUS mode where the tag
remains in the same position within the Data Chunk but interpreted by a
process associated with the Stream and not used for direct placement.  The
SCSI PDUs are contained within a Data Chunk and SCTP provides assured
structure-packet alignment with a fixed location of the CRC digest.

http://groups.yahoo.com/group/SCTP-DDP/files/

Doug

> Excerpt of message (sent 1 March 2002) by Julian Satran:
> > Pat,
> >
> > We discussed several alternative formats including a separate
> > protection (parity) for the length fields. All where dropped.
> > The probability of an undetected error of length 1 in the header
> > - using a CRC32 is 0 and holds at 0 for bursts up to 31 bits.
>
> That's a true statement for CRC-32 for the case where you've correctly
> identified where the CRC field is in the data.
>
> If you use the wrong value for the length (and therefore the wrong
> value for the position of the CRC) then you have a 2^-32 probability
> of accepting the header as valid.
>
> So the question becomes: how big a change to the header is needed to
> make you look for the CRC field in the wrong place?  The answer is one
> bit, because any one-bit change to the TotalAHSLength field does
> that.  You might be able to make this less likely by using a rule that
> only some TotalAHSLength values are valid, but that doesn't change the
> outcome.  The values 0 and 2 are both legal, and these differ in only
> one bit.
>
> So Pat is right: given the encoding chosen, the Hamming distance is
> one.
>
> > ...
> > In addition the logic for putting the header digest at a fixed
> > position but including the AHS in the digest has the same flaw.
>
> That's true.  For example, if a single bit error changes the
> TotalAHSLength from 0 to 2, even if you put the CRC in a fixed place,
> you have just changed the bitstring it acts on by 64 bits.  That's
> longer than the burst error limit of CRC-32, so there is a non-zero
> probability of accepting such a damaged header as valid.
>
> > There are some radically different layouts - that may include a
> > framer and lengths protected by CRCs and followed by Data+Header
> > protected by a single CRC.  But we may want to leave those for
> > iSCSI-2 :-)
>
> That one would work.  (It's how DDCMP was done...)  And I agree,
> that's not a solution to be considered now.
>
>        paul
>
>