Re: iscsi: header digest issue

[Paul Koning <ni1d@arrl.net>]

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
> 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