RE: FCIP iFCP encapsulation proposal

["Y P Cheng" <ycheng@connectcom.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

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.