SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: FCIP iFCP encapsulation proposal



    Steph
    
    I will not argue with your opinion of the value of running synch 
    rediscovery, but I disagree with the observance that the chance of 
    spoofing the resynch mechanism is a linear "one in n". Although not 
    directly mentioned in the document, it is implied that the 
    qualification for a CRC acceptance on the payload portion be 
    restrained to assume only a payload length which exactly matches the 
    length as defined in the length field of the tentative header. Certain 
    reality checks on the other header fields would not be out of order 
    either.
    
    Lani
    
    Stephen Bailey wrote:
    
    >> 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.
    
    


Home

Last updated: Tue Sep 04 01:05:23 2001
6315 messages in chronological order