RE: FCIP iFCP encapsulation proposal

[Vi Chau <vchau@gadzoox.com>]

   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


> -----Original Message-----
> From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
> Sent: Monday, March 12, 2001 5:59 AM
> To: ips@ece.cmu.edu
> Subject: Re: FCIP iFCP encapsulation proposal 
> 
> 
> > 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
>