RE: FCIP iFCP encapsulation proposal

["Merhar, Milan" <mmerhar@pirus.com>]

Vi,

I think the point that was being presented is that
the proposed protocol is open to malicious attack by an 
end station that _would_ create such data patterns
(e.g. - as part of an image written to a filesystem,)
and then attempts to take down the FCIP link
by repeatedly causing that pattern to traverse the link.

The usual rule of thumb is to assume the worst-case
situation - that a "unique" data pattern used for 
control is truly unique only if active measures are 
taken to prevent its occurance elsewhere.
Examples include FC framing (using 10bit sequences 
that do not map to normal 8bit characters) and HDLC/SDLC
(which actively bit-stuffs to prevent normal data from 
containing the special 6-ones-in-a-row pattern.)
Neither of these approaches is probably viable here, 
as the overhead of bit-level manipulations and mappings 
without dedicated hardware would be onerous. 

Sonet introduces a bit-level scrambling onto the data 
stream, to prevent the introduction of a data pattern 
that might trigger the line fault detector.  This doesn't
so much eliminate the "magic sequence" of a long stream 
of zeroes, but instead obscures it, turning it into a 
long pseudo-random sequence.

Even in the latter case, there have been concerns 
that some higher-level protocols, such as AAL5 over
ATM over Sonet, allow too much flexibility in the 
payload data, potentially permitting someone to transmit 
the compliment of the bit-scrambling sequence, and thereby 
inducing a datalink fault!

So, I guess the take-away from this conversation is that
some people are very conservative (some would read that
as "paranoid" ;-) but the measures they demand _will_ 
result in a more robust transport spec.  

And, if that's so, the real discussion IMHO is how to provide 
such robustness with reasonably low cost/complexity.

Best regards,
	Milan




> -----Original Message-----
> From: Vi Chau [mailto:vchau@gadzoox.com]
> Sent: Friday, March 09, 2001 6: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.
> > 
>