RE: FCIP iFCP encapsulation proposal

[Douglas Otis <dotis@sanlight.net>]

Milan,

With trusted routers and secure name servers, spoofing and not man in the
middle is of concern.  Variable length framing opens up many possibilities
for spoofing, as spoofing could attempt a series of validations.  A simple
solution would be to use two levels of framing.  One at a fixed interval and
a sub-layer that allow FC frames to be fragmented to fit within these fixed
interval frames or pseudo-frames.  The sub-layer could be a vanilla version
of SCTP padded out to fit if required as it also provides the means of
acknowledging pseudo-frames and the extensibility desired in a general
purpose framing algorithm.  This does two things.  It allows error checking
to be done a the pseudo-frame level rather than on a PDU basis and also
allows this well defined length pseudo-frame to be retried.  The overhead
for such a scheme would be low as it should be rare pseudo-frames would
require padding.  If done within TCP, simply substitute SCTP ports with a
pseudo-frame length.  This ensures error checking is limited to a reasonable
length rather than large PDUs found with iSCSI as example, if done in a
general purpose mode and ensures memory requirements are defined for the
transport.

Doug

> 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.
> > >
> >
>