RE: FCIP iFCP encapsulation proposal

[Black_David@emc.com]

I don't think Bob's understood the issue -- If a trace file containing
all the headers and framing information from traced FCIP
communications is stored through FCIP it must be the case that
any framing mechanism used by FCIP does not get confused by
the framing information in the trace file.  If the framing mechanism
gets confused and attempts to execute the (correctly formed)
frames contained in the trace file, sooner or later, something
visibly disastrous *will* happen (e.g., my FORMAT command
example :-) ).  This is a design constraint on the framing
mechanism, and Vi Chau's email that started this thread
proposed a framing mechanism that did not meet this
design constraint.  The initial proposal is appreciated, but the
WG is obligated to do better.

Beyond that, Bob's characterization of the difficulty of inserting
traffic into a TCP session is way off the mark.  In the hope of
avoiding further expenditure of list bandwidth on the discussion
of fundamentally inadequate security mechanisms and
approaches, I want to remind people of the following:

(1) TCP hijacking is a well-known attack in which the attacker
	takes over one end of the connection.  Exploit code is
	readily available for this.  Not only is it not difficult - it's
	actually a solved problem (unfortunately).  The exploit
	code monitors the TCP connection to learn its state and
	then injects just the right packets to take it over.
(2) Creation of a "properly defined TCP connection" is not in
	general a "secure action".  Even in the specific cases
	where it is (e.g., in-band authentication is used), a
	hijack attack can be launched after the authentication
	if there is no cryptographic data integrity used on the
	connection.
(3) The entire discussion about the difficulty of reproducing
	Fibre Channel related state makes the common mistake of
	confusing obscurity and/or complexity with actual security.
	TCP has already been hacked in this "darned unlikely"
	fashion -- it's just a matter of time before someone with
	nothing better to do figures out how to get just enough
	of FC-2 right in order to do serious damage to/via FCIP.

In particular, I have some serious problems with:

> In effect, the problem is not a "frame in data" problem.  It is a 
> "frame in successfully delivered TCP/IP data across a legitimate
> TCP/IP connection consistent with the fully defined states of
> the Fibre Channel FC-2 layer and consistent with the states, 
> requirements, requests, and acknowledgements of the upper layer protocol" 
> problem, which is darned unlikely even if you are trying maliciously 
> to do it.

As indicated above, the "frame in data" problem involves
a framing mechanism that gets confused about where the
frames are and makes the mistake of extracting a
frame from the data.  I hope everyone agrees that any 
framing mechanism design MUST prevent this.

Second, "darned unlikely" is an inadequate level of security
assurance.  What's required is "can't happen" backed by a
discussion of the cryptographic difficulty involved in making it
happen when appropriate security mechanisms are used. 
I realize that all cryptographic assurance arguments come
down to some version of "darned unlikely" (e.g., if the
adversary correctly guesses the key(s) involved, it's all
over), but the level of difficulty involved for reasonable
security mechanisms is generally well beyond that
of grabbing some FC-2 code and grafting it onto TCP
hijack code.

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