Subject: Re: iscsi: header digest issue

From: "Julian Satran" <[email-masked]>
Date: Sat, 2 Mar 2002 10:19:56 +0200

the logit is bit more trickier - with 1 bit distance you will get to a 
WRONG CRC - Julo

Paul Koning <[email-masked]>
01-03-02 19:07

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked], [email-masked]
        Subject:        Re: iscsi: header digest issue

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

---

From: Paul Koning <[email-masked]>
Date: Sun, 3 Mar 2002 14:00:51 -0500

> the logit is bit more trickier - with 1 bit distance you will get to a 

I don't see why that it so.  

If a bit error changes AHSLength from 0 to 2, the receiver will take
the header that was sent -- with its digest -- and process that PLUS
the next 8 bytes after the header through its CRC (because it thinks
the header is 8 bytes longer than what the sender intended).  That's a
64 bit error burst.  CRC-32 has the property that it will fail to
detect a 64 bit burst with probability roughly 2^-32.

Therefore, not all 1-bit errors will be detected.

I don't see what tricky logic can get you around this case, but if you
know of some, could you say what it is?

     paul