Subject: RE: FCIP iFCP encapsulation proposal

From: Vi Chau <[email-masked]>
Date: Fri, 9 Mar 2001 15:20:48 -0800

Stephen,

   I am confused by your argument. The re-synchronization that we
proposed is between two FCIP devices/ports; why would one side want
to confuse the other side by sending patterns that cause false
re-synchronization? FCIP devices are defined to be the providers
of tunnels for FC data to pass through. So the users of the FCIP
devices are the FC end nodes that want to communicate with each
other so they do not have a tendency to intentionally send
confusing or "cooked" data patterns.

Vi

> -----Original Message-----
> From: Stephen Bailey [mailto:[email-masked]]
> Sent: Friday, March 09, 2001 7:42 AM
> To: [email-masked]
> Subject: Re: FCIP iFCP encapsulation proposal 
> 
> 
> > There is a remote possibility that a false compare could occur
> > from other data in the stream so it is necessary to continue to
> > check the "tentative" FCIP/iFCP payload and CRC also before
> > assuming a correct synchronization. If both CRC checks are good,
> > this certification should be at least as good as the data
> > integrity provided by the CRCs in a synchronized stream.
> 
> Nonsense.
> 
> The original FCIP proposal that the receiver scan for an EOF/HDR/SOF
> sandwich to recover synchronization has the same problem.  This
> technique is fundamentally bogus.
> 
> Any time you're scanning user-controllable data (as in from the
> completely uncontrolled, end application), you MUST assume absolute
> worst case (to fool the sync algorithm) data.  In the worst case, the
> probability of faking out your resynchronization heuristic is much
> (!!!) greater than the probability of an integrity CRC giving you a
> false positive acceptance check.
> 
> In other words, the user can pack the data stream with `cooked' data
> patterns that are just waiting for a dropped frame and an attempt to
> resynchronize.  If you assume that the shortest pattern required to
> fool the resynchronization algorithm is n words (no longer than the
> minimum well-formed PDU size), and TCP segmentation is effectively
> random (*), the chance of your resynch algorithm getting spoofed
> (resulting in the user getting some control of trusted `machinery') is
> simply 1 in n.
> 
> You can fix this problem by using a shared `secret' (from the client)
> between the two endpoints.  For example, if you put a 64-bit random
> number that both endpoints know in the end/begin sandwich, THEN you
> can talk about vanishingly small probabilities of the sandwich
> discovery going wrong.
> 
> Personally, I think this running sync rediscovery is all makework
> because it's still a far distant second (or third, if you like
> periodic markers) to ensuring that each segment is sufficiently
> self-describing (AKA framing).  A framing solves several other
> problems, such as the digest failure problem currently being discussed
> by Julian & Somesh.
> 
> Steph
> 
> * It isn't but, AGAIN, you must make WORST CASE assumptions, because,
> with properly periodic or aperiodic patterns, the user can actually
> encourage the segmentation algorithm to work in her favor.
>

---

From: Vi Chau <[email-masked]>
Date: Mon, 12 Mar 2001 10:03:07 -0800

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.
Speaking of which, there is this, from Julian's reply in the iSCSI
"lengths and header digest error recovery" thread:

> You have to take some elements as good and try to recover. This holdsfor
> those protocols that have length as demarcation element and for those that
> have framing patterns for demarcation as framing patterns can also be bad.
> You recover at another frame boundary or another marker.

   Same issue as what we are talking about here.

   Using a special pattern for frame delineaton does not get
around this problem as there is no guarantee that the same pattern
does not appear in the payload (unlike the case of HDLC or Sonet which
operate at a lower protocol layer); and a malicious user can create
well-formed packets that carry the special framing pattern designed to
fool the receiver.

   Perhaps security should be considered together with encapsulation
if enough people think this is a serious concern.

Vi

> Sent: Monday, March 12, 2001 5:59 AM
> To: [email-masked]
> > I can envision a case where the user embeds a sequence of several
> > well-formed PDUs in such a payload to handle the case where
> > resynchronization requires the detection of more than one good
> > encapsulation.
> 
> Precisely.
> 
> In fact, in fact, I just realized (once again), that I'm an
> idiot---the chance of user getting control with a repeating set of
> valid PDUs is actually MUCH higher than 1 in # of words in the PDU.
> 
> If the TCP segment begins with the start of a PDU, the user will not
> get control.  If the TCP segment begins at any other point, the scan
> will proceed (failing to resynch) until it reaches the beginning of
> one of the user's spoofing PDUs, at which point resynching will
> succeed (erroneously), and the user will have control, at least until
> the end of the current, actual PDU.
> 
> In other words, the chances are remote that a stream of PDU patterns
> in the user data WON'T cause resynchronization to occur erroneously.
> 
> As to why would this happen---to watch it burn.  Why not?  Script
> Kiddies abound.  Personally, if I were a 12 year old, hacking on my
> school's shared 11/34 running RSTS/e, I'd blindly stumble around
> trying different SYS(xxx) calls too.
> 
> Steph
>

---

From: [email-masked]
Date: Mon, 12 Mar 2001 14:38:58 -0500

> 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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: [email-masked]
Date: Wed, 14 Mar 2001 11:17:15 -0500

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

---

From: Robert Snively <[email-masked]>
Date: Wed, 14 Mar 2001 09:47:13 -0800

Dave,

The byte stream that is processed by the iSCSI or FCIP layer is
not a byte stream that can be generated by a hardware spoofer.
It is the byte stream that is delivered by a TCP connection, riding
on PDU's containing IP headers, riding on Ethernet frames carrying their
own identification information.  The spoofer must successfully generate
an output that will meet the Ethernet format requirements for delivery,
including device addressing; will then meet the IP requirements for delivery,
including frame identification, IP addressing, fragmentation and
reassembly, and CRC; will then meet the TCP/IP requirements for delivery,
including proper TCP header formatting, proper checksumming, proper
identification of the order and location of data, and the definition of
a properly defined TCP connection, which can in turn only be 
created by a secure action which cannot be replicated; will then meet the
requirements of an FC frame, including sequence id and frame count, exchange 
identification by both the source and sink, address verification by
the sink, consistency with login state, and 32-bit CRC; and will finally 
meet the logical and state dependent requirements of the upper layer 
protocol, including logical unit addressing, command set requirements,
consistency with read and write operations, and status presentation;
all without being noticed. 

It will be very hard for you to convince me that this can all be done
by dropping Ethernet frames with a bunch of replicated FCIP frame headers
into a fabric.  What you have to do is realistically and undetectably
meld the TCP data stream from the legitimate connection and the TCP
data stream from the false connection in a manner seamless enough so
that the data will get delivered.  Then, after delivering the data, you
have to reconstitute a legal SCSI, VI, or other Fibre Channel protocol
in a manner that will not cause it to be rejected or timed out by the
higher level protocol.  This by the way is one of the advantages of having
long connection periods.  There are very infrequent opportunities to
formulate a potentially legitimate TCP/IP connection capable of carrying
falsified data.  There is of course the unfortunate side effect that,
once you have succeeded in creating such a connection, you can obtain
all the rights associated with such a connection, in which case no
framing behavior could protect you anyway. 

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.

Bob

>  From: [email-masked] [mailto:[email-masked]]
>  Sent: Wednesday, March 14, 2001 8:17 AM
>  To: [email-masked]; [email-masked]
>  Subject: RE: FCIP iFCP encapsulation proposal
>  
>  
>  Bob,
>

---

From: [email-masked]
Date: Thu, 15 Mar 2001 10:18:42 -0500

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.

> problem, which is darned unlikely even if you are trying maliciously 

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