RE: FCIP iFCP encapsulation proposal

[Robert Snively <rsnively@Brocade.COM>]

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