Re: iSCSI Some Thoughts on Digests

[Glen Turner <glen.turner@aarnet.edu.au>]

Black_David@emc.com wrote:
> 
> This appears to answer the original question about why CRC digests
> have been proposed as iSCSI-specific ;-).  The end to end 32 bit
> CRC requirement is somewhat specific to iSCSI, since protocols
> such as http are quite happy without it.

Hi David,

The short answer is that HTTP is *not* "quite happy without it".

Stone and Partridge's paper in the ACM SIGCOMM 2000 Proceedings
shows that errors that have a source other than the link layer
are disturbingly common.

iSCSI also needs better data integrity then HTTP because it is used in
a mode where errors across time will accumulate.  For example,
an error per 100000 web pages viewed has no effect that is not
solved by hitting the Reload button.  An error per 100000 files
written would lead to an error every time the unlucky file was read.

> For the purposes of the original question, I don't think the position
> that security is needed whenever integrity is needed (which lead to
> the notion of using IPsec for 32 bit CRC-grade integrity) is tenable.  I
> would expect to see all sorts of private and semi-private addressing
> used with iSCSI, including LANs/VLANs that won't switch/route layer
> 3 addresses, and folks who believe that they're safe behind a firewall.

The main problem with IPSec is that it may not protect
the data from corruption if it is offloaded.  For example,
a DMA or memory bit error would still be undetected.

A technology choice that is implemented by the CPU is
desirable.  For this reason, the IEEE CRC32 isn't too
flash a choice either, as it is a bit-twiddling rather
than word-twiddling checksum[1].

The crypto digests are simply overkill -- they don't provide
protection from malicious alteration when used in the iSCSI 
protocol and when used for detecting non-malicious alteration
they are less efficient than a CRC.

Finally, a common algorithm is desirable.  This is because
hosts will already have an implmentation of that common
algorithm (with its tables, etc) in the kernel memory which
can be re-used.

With all these considerations, the IEEE CRC32 (and initialised
with 0xffffffff) is probably the best option.

Note that the draft needs to insist upon a CPU implementation
of the checksum/CRC if it is to be effective.  Implementations
that implement the checksum/CRC on some soft or offload
processor should be discouraged as this limits the modes
of detectable failures.

Glen

[1] The bit twiddling can be avoided by table lookup, but
    that simply moves the argument to one of relative memory
    consumption.

-- 
 Glen Turner                                 Network Engineer
 (08) 8303 3936      Australian Academic and Research Network
 glen.turner@aarnet.edu.au          http://www.aarnet.edu.au/
--
 The revolution will not be televised, it will be digitised