RE: FCIP iFCP encapsulation proposal

[Black_David@emc.com]

>    From reading the notes on this thread since Friday, it is clear
> to me that this is a security (authentication) problem and not a
> framing (re-synch) issue since without an authentication mechanism,
> no framing scheme is safe from spoofing or malicious actions.

While the examples that people are using to critique the design
involve malicious attacks, the resync mechanism must ensure
that data is not mistaken for headers even in the absence of
malicious attacks.  Here's a perfectly reasonable scenario --
consider using a protocol tracer to dump every bit transmitted
on an FCIP connection to a binary trace file for debugging.
Now ftp that file to a server for further examination, and suppose
there's another FCIP link between the server and its storage.

There MUST NOT be any way for the far end of the FCIP link
to get confused and start to treat the contents of the binary
trace file that is being written to storage as FCIP frames, even
though the contents look like FCIP frames (e.g., what if one
of the frames in the trace file is a FORMAT command?).
If a special data pattern is used to trip resync, the special
pattern has to only occur at resync points.  There are a
number of worked examples of this, including PPP byte-stuffing,
and the 8b/10b coding used for both Gigabit Ethernet and Fibre
Channel.

--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
---------------------------------------------------