RE: FCIP iFCP encapsulation proposal

[Black_David@emc.com]

Bob,

> Sorry, I think we have a severe case of red herring here.  Any number of
> unlikely scenarios has been hypothesized, none of which (assuming
> there is any security in creating a TCP/IP connection at all) will
> cause any useful or dangerous behavior in either a SCSI target or
> a SCSI initiator.
> 
> As an example, the information transmitted by FTP is first processed into 
> FTP messages, 

The ftp analogy is not indicative of what's going on here because ftp does
not
have a resync mechanism - in other words, ftp never scans the inbound byte
stream from TCP looking for some data pattern that indicates the start of
an ftp message.  Some of the "framing" proposals for iSCSI, iFCP, and
FCIP propose to do this or something close to it.

The most severe case is one in which the framing data pattern is used to
identify
a message that will be processed by SCSI or FC logic in an upper layer.
iSCSI
needs to do this after a CRC failure if the CRC failure requires discarding
the
length information in a header and the connection is not closed.  In this
case,
occurrence of the framing pattern in data could cause a PDU to be extracted
from the data and processed - this would be very bad.

If framing is used only for data steering (i.e., organization of buffer
memory for
data that has been received, but not yet processed), the situation is
better, but
it's necessary for logic somewhere to know that the memory organization
done by the framing may not always be correct, and be prepared to copy the
data to get it correctly organized (e.g., 4k data block on a 4k boundary) if
necessary.

Going back to Vi Chau's encapsulation proposal at the start of this thread,
there's a separate header CRC.  If the header CRC check fails, the frame
length info in that header cannot be used.  If the TCP connection is not
closed at that point, the arriving data has to be scanned looking for the
next header.  Vi wrote:

> In the event of loss of synchronization, a state machine which normally
> checks the FCIP/iFCP header CRC can be continuously enabled on the
> data stream which should provide for a "good CRC" compare when an
> FCIP/iFCP header arrives.

This is subject to exactly the "frame in data" problem caused by storing
a trace file - the state machine will find what looks like a good header in
what's actually data, process it (and perhaps several, if a number of short
trace frames are included in the actual data frame), only realizing its
mistake
at some later point.  This MUST NOT be allowed to happen.

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------