RE: header and data digest issue

[Black_David@emc.com]

Bob,

> IPsec ESP cryptographic integrity is too expensive (at least for me).
> 
> It seems likely that a iSCSI aware middle box will DMA the header
> and data separately. If this is the case than it seems likely that
> eventually the data will be DMAed to the wrong place.
> This could be caused by software, firmware, or hardware.

The whole point of separate CRCs on header and data was to allow
an iSCSI middlebox to modify the header without having to touch
the data CRC.  As I said, a CRC will not prevent this middlebox problem
- for example, if iSCSI had a CRC that covered both headers and data,
one would almost certainly see middleboxes that stripped that CRC
on input and regenerated it on output, producing a vulnerability to
the problem of concern.  Something like IPsec ESP cryptographic
integrity that a middlebox cannot regenerate is necessary to solve
this problem.  This is a long version of a fairly simple principle
- those who don't trust middleboxes shouldn't allow their use.

> It also seems likely that a software error in the target operating
> system will also cause this problem.  Again because it is likely that
> the header and data will be manipulated differently.  It is a very
> minor coding error to cause this behavior. Just mess up a circular
> queue, or some off by one bug.

I agree, bugs happen.
 
> I am writing software that processes and stores iSCSI data.
> I will have the iSCSI target (whether software or off-board processor)
> pass me the CRC digests in addition to the header and data.
> The CRC digests are verified and stored on disk with the header and data.
> This provides a high degree of confidence that the data on disk is
> either correct and at its correct address, or that it can be detected
> that it is not.  Additionally this architecture allows fsck type
> software to be written to walk the disk looking for CRC errors.

This is not an "off-the-shelf" target, as a vanilla iSCSI target will
consume the header, passing only selected pieces of it upward (e.g.,
nothing above iSCSI needs to know about CmdSNs, nothing above SCSI
knows about CDBs).  So the target is going to have to be modified
to work with your software.

> By using the CRCs generated by the initiator and verified by
> my software, I have a high degree of confidence that my own
> software or the operating system software did not introduce errors.
> 
> The iSCSI header and data digests are almost perfect for implementing this
> architecture. But by computing CRCs separately for the address and the
data,
> there is a non-negligible chance that my software will write the wrong
data
> to a block. Not only will I be unable to detect the problem when it
occurs,
> a scan of the disk and CRCs will indicate that nothing is wrong.
> Only the application will know that the data is wrong.

Since the target has to be modified anyway, here's a simple modification
to it that accomplishes this goal without any changes on the wire:
	When the target first scans the iSCSI PDU, it not only
	extracts the two CRCs, but also calculates their XOR,
	and passes all three values upward in addition to the
	iSCSI header and data.  Your software checks and store
	all three values with the header and data.
If something in the target or the OS or your software screws up and
swaps the header (and its CRC), the XOR will catch this.  Let me know
if this works for you.

For the middlebox problem, ESP cryptographic integrity is the right
solution, as any CRC-based mechanism will be defeated by a middlebox
implementer taking fairly obvious and convenient "strip and regenerate"
shortcuts.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------