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



    
    
       From reading the notes on this thread since Friday, it is clear
    to me that this is a security (authentication) problem and not a
    framing (re-synch) issue since without an authentication mechanism,
    no framing scheme is safe from spoofing or malicious actions.
    Speaking of which, there is this, from Julian's reply in the iSCSI
    "lengths and header digest error recovery" thread:
    
    > You have to take some elements as good and try to recover. This holdsfor
    > those protocols that have length as demarcation element and for those that
    > have framing patterns for demarcation as framing patterns can also be bad.
    > You recover at another frame boundary or another marker.
    
       Same issue as what we are talking about here.
    
       Using a special pattern for frame delineaton does not get
    around this problem as there is no guarantee that the same pattern
    does not appear in the payload (unlike the case of HDLC or Sonet which
    operate at a lower protocol layer); and a malicious user can create
    well-formed packets that carry the special framing pattern designed to
    fool the receiver.
    
       Perhaps security should be considered together with encapsulation
    if enough people think this is a serious concern.
    
    
    Vi
    
    
    > -----Original Message-----
    > From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
    > Sent: Monday, March 12, 2001 5:59 AM
    > To: ips@ece.cmu.edu
    > Subject: Re: FCIP iFCP encapsulation proposal 
    > 
    > 
    > > 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.
    > 
    > 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
    > 
    


Home

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