RE: iSCSI: CRCs

[Michael Krause <krause@cup.hp.com>]

At 07:47 PM 1/24/2001 -0500, Black_David@emc.com wrote:
>As I recall the discussion, it was about facilitating
>iSCSI to iSCSI "middle boxes" - gateways, proxies,
>etc. of various forms that may want to muck with
>the header for some reason.  Such a box is a target
>on one iSCSI connection and initiator on another,
>and only having to regenerate the header CRC
>makes such a box easier to implement, and improves
>the protection obtained from the data CRC.

This is extremely dangerous since the header could be corrupted in the 
intermediate element and one acts upon the header for determining where the 
payload is going to be placed.

To support such a solution would require one to use a similar scheme to 
what is provided in InfiniBand:

- Clear delineation of what fields are variant and what are not.

- A variant CRC that covers the variant fields and the rest of the PDU.

- An invariant CRC that does not cover the variant fields but does cover 
the invariant fields and the rest of the PDU.

This scheme insures there is no time that critical header / data fields are 
not protected end-to-end allowing one to have a strong data integrity 
solution.  BTW, InfiniBand uses a 16-bit variant CRC and a 32-bit invariant 
CRC.  InfiniBand also does this per packet which goes to another issue with 
the current draft which is the problem of a PDU spanning multiple TCP 
segments - more on that in a separate e-mail.

Mike