Subject: RE: FCIP iFCP encapsulation proposal

From: Charles Monia <[email-masked]>
Date: Fri, 9 Mar 2001 17:57:04 -0800

Hi Vi:

My .02:

I assume the argument is that a malicious end user could generate an FC
payload stream filled with a bogus synchonization signature.  One way to
generate such a stream is to create a large file filled with such data.  The
malicious user then does a continuous read in the background, assuming that
an error will eventually trigger the need to recover synchronization. 

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.

Charles
> -----Original Message-----
> From: Vi Chau [mailto:[email-masked]]
> Sent: Friday, March 09, 2001 3:21 PM
> To: [email-masked]
> Subject: RE: FCIP iFCP encapsulation proposal 
> 
> 
> Stephen,
> 
>    I am confused by your argument. The re-synchronization that we
> proposed is between two FCIP devices/ports; why would one side want
> to confuse the other side by sending patterns that cause false
> re-synchronization? FCIP devices are defined to be the providers
> of tunnels for FC data to pass through. So the users of the FCIP
> devices are the FC end nodes that want to communicate with each
> other so they do not have a tendency to intentionally send
> confusing or "cooked" data patterns.
> 
> Vi
> 
> > -----Original Message-----
> > From: Stephen Bailey [mailto:[email-masked]]
> > Sent: Friday, March 09, 2001 7:42 AM
> > To: [email-masked]
> > Subject: Re: FCIP iFCP encapsulation proposal 
> > 
> > 
> > > There is a remote possibility that a false compare could occur
> > > from other data in the stream so it is necessary to continue to
> > > check the "tentative" FCIP/iFCP payload and CRC also before
> > > assuming a correct synchronization. If both CRC checks are good,
> > > this certification should be at least as good as the data
> > > integrity provided by the CRCs in a synchronized stream.
> > 
> > Nonsense.
> > 
> > The original FCIP proposal that the receiver scan for an EOF/HDR/SOF
> > sandwich to recover synchronization has the same problem.  This
> > technique is fundamentally bogus.
> > 
> > Any time you're scanning user-controllable data (as in from the
> > completely uncontrolled, end application), you MUST assume absolute
> > worst case (to fool the sync algorithm) data.  In the worst 
> case, the
> > probability of faking out your resynchronization heuristic is much
> > (!!!) greater than the probability of an integrity CRC giving you a
> > false positive acceptance check.
> > 
> > In other words, the user can pack the data stream with `cooked' data
> > patterns that are just waiting for a dropped frame and an attempt to
> > resynchronize.  If you assume that the shortest pattern required to
> > fool the resynchronization algorithm is n words (no longer than the
> > minimum well-formed PDU size), and TCP segmentation is effectively
> > random (*), the chance of your resynch algorithm getting spoofed
> > (resulting in the user getting some control of trusted 
> `machinery') is
> > simply 1 in n.
> > 
> > You can fix this problem by using a shared `secret' (from 
> the client)
> > between the two endpoints.  For example, if you put a 64-bit random
> > number that both endpoints know in the end/begin sandwich, THEN you
> > can talk about vanishingly small probabilities of the sandwich
> > discovery going wrong.
> > 
> > Personally, I think this running sync rediscovery is all makework
> > because it's still a far distant second (or third, if you like
> > periodic markers) to ensuring that each segment is sufficiently
> > self-describing (AKA framing).  A framing solves several other
> > problems, such as the digest failure problem currently 
> being discussed
> > by Julian & Somesh.
> > 
> > Steph
> > 
> > * It isn't but, AGAIN, you must make WORST CASE 
> assumptions, because,
> > with properly periodic or aperiodic patterns, the user can actually
> > encourage the segmentation algorithm to work in her favor.
> > 
>

---

From: Stephen Bailey <[email-masked]>
Date: Mon, 12 Mar 2001 08:58:53 -0500

> resynchronization requires the detection of more than one good

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