RE: FCIP iFCP encapsulation proposal

[Douglas Otis <dotis@sanlight.net>]

Bob,

With out discussing spoofing where attackers successfully guess TCP
sequences (made too easy in some cases), a binary image is stored and then
legitimately sent as a payload, with the example being binary content of a
debug analyzer.  In this case, headers contained within the payload could be
seen as valid.  The valid header within the payload may fool a process that
attempts to recover header synchronization following a dropped packet.  This
header may carry the same information in current use and be acted upon or
send the connection into error oblivion. It would appear to represent a
weakness that can be exploited.  Dropped packets happen.

Doug

> 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
>
> >  -----Original Message-----
> >  From: Black_David@emc.com [mailto:Black_David@emc.com]
> >  Sent: Wednesday, March 14, 2001 8:17 AM
> >  To: rsnively@brocade.com; ips@ece.cmu.edu
> >  Subject: RE: FCIP iFCP encapsulation proposal
> >
> >
> >  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
> >  ---------------------------------------------------
> >
> >
>