RE: FCIP iFCP encapsulation proposal

[Charles Monia <cmonia@NishanSystems.com>]

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:vchau@gadzoox.com]
> Sent: Friday, March 09, 2001 3:21 PM
> To: ips@ece.cmu.edu
> 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:steph@cs.uchicago.edu]
> > Sent: Friday, March 09, 2001 7:42 AM
> > To: ips@ece.cmu.edu
> > 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.
> > 
>