Subject: RE: FCIP iFCP encapsulation proposal

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

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Mar 2001 13:15:00 -0800

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

---

From: "Y P Cheng" <[email-masked]>
Date: Wed, 14 Mar 2001 18:23:19 -0800

> 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

Like Bob said, this is a lot of red herring.  First, I don't agree with
scanning the payload to resync.  There are better ways.  But, if scanning is
done, the probability of sending the TCP connection into error oblivision by
mistaking the payload for a valid "frame" is almost non-existence.  There is
a lot information inside a FC frame that must be checked.  Let me just name
a few, SOF, S_ID, D_ID, OX_ID, RX_ID, Seq_ID, Sequence Count, R_CTL, F_CTL,
CS_CTL, DF_CTL, Data Offset, and EOF etc.  OK, so you got the trace data
that seem to have all the valid stuff.  It is NOT just these fields looking
like a valid frame; they MUST match the saved  information inside a valid
Exchange Control Block (ECB) refer to by the OX_ID and RX_ID.  Without
matching the saved information in an ECB, the frame is always discarded.

Y.P. Cheng, ConnectCom Solutions.

---

From: Stephen Bailey <[email-masked]>
Date: Thu, 15 Mar 2001 09:18:02 -0500

> It is NOT just these fields looking like a valid frame; they MUST
> match the saved information inside a valid Exchange Control Block
> (ECB) refer to by the OX_ID and RX_ID.

Not if the frame begins a new exchange.  Instead of concentrating on
FCP_DATA, and the read (target->initiator) direction, look at other FC
PDUs and the write direction (initiator->target).

A single frame could be an FCP_CMD with a SCSI command, (e.g.  RESERVE
or START STOP UNIT with LOEJ=1), or a task management function
(e.g. target reset) or an FC link service (e.g. LOGO).  I'm sure there
are more clever attacks too.

The only thing you need to know is the FC IDs of a logged-in
target/initiator pair which share the TCP connection you're using.
Certainly, the easiest pair would be the attacking system's FC_ID and
the target from which you are launching the attack (i.e. the target to
which you are directing the stream of write data).  However, if you
know other logged-in FC_ID pairs, you can also do a 3rd party attack.

It is not the case that FC_IDs are going to be well kept secrets which
will require a 'til the sun grows cold parameter search.

Steph

---

From: "Y P Cheng" <[email-masked]>
Date: Thu, 15 Mar 2001 08:25:04 -0800

Stephen Bailey
> Certainly, the easiest pair would be the attacking system's FC_ID ...

To begin a new exchange in an Internet environment, I do hope we check stuff
more than just FC_ID before allowing a START_STOP_UNIT or TARGET_RESET.
After a successful login and text message exchanges, both initiator and
target keep a Port/Connection Control Block to save all kinds of goodies
resulting from the exchanges.  The goodies WILL be checked before allowing
an operation.  If not, there is no security and all the discussions herein
are somewhat academic.  Furthermore, if the login and text messages are
easily stolen, it is a security issue not an operation issue.

Y.P.

---

From: "Y P Cheng" <[email-masked]>
Date: Thu, 15 Mar 2001 08:25:04 -0800

Stephen Bailey

Y.P.