SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: [Tsvwg] [SCTP checksum problems]



    
    
    Steph,
    
    You may want to add that one of the reasons for having an iSCSI integrity
    check is to enable iSCSI PDU handling by middle boxes (separate header and
    data digests).
    And the integrity check can be made tamper proof to a greater extent by
    changing from a error detection digest (CRC) to a full-fledged
    authentication digest (that option exists in iSCSI too).
    
    As for the transience of the bad middle boxes - hard to believe - new ones
    are born every day now (with more software!) -:)
    
    Julo
    
    
    
    Stephen Bailey <steph@cs.uchicago.edu> on 19/04/2001 00:09:02
    
    Please respond to Stephen Bailey <steph@cs.uchicago.edu>
    
    To:   "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>
    cc:   "'WENDT,JIM (HP-Roseville,ex1)'" <jim_wendt@hp.com>, Julian
          Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu, tsvwg@ietf.org, "'Craig
          Partridge'" <craig@aland.bbn.com>, Jonathan Wood
          <Jonathan.Wood@sun.com>, xieqb@cig.mot.com, Jonathan Stone
          <jonathan@dsg.stanford.edu>, Randall Stewart <rrs@cisco.com>
    Subject:  Re: [Tsvwg] [SCTP checksum problems]
    
    
    
    
    Vince,
    
    > I don't think iSCSI can be completely relieved of performing some data
    > integrity checking as long as there exists the possibility of "middle
    boxes"
    > opening up the transport protocol's packet and thus potentially
    invalidating
    > any reliability guarantees the transport protocol makes.
    
    Any protection provided against this failure mode will only be
    transient, so we must temper the desire to introduce such a
    requirement with reality.
    
    Middleboxes can just as easily open up to the iSCSI layer and tinker
    with the payload, as they do with other ULPs running on TCP (e.g HTTP)
    today.  Short of securing the connection, there is ALWAYS a
    possibility of a middlebox terminating and reoriginating an integrity
    check.  In case you think this is a farfetched scenario, I do get the
    impression that there is a high level of interest in `actively
    middling' iSCSI once the specs crystalize.  Who shaves the barber?
    
    An integrity check is not necessary as long as some lower layer
    provides adequate integrity guarantees.
    
    Adding an integrity check above the transport layer is based upon
    documentation of the presence of a lot of crappy network hardware and
    software and analyses of the transport integrity check (TCP checksum)
    which suggests it might not be adequately strong against some such
    observed errors.
    
    I claim that the high incidence of `broken' (corruption introducing)
    components is a result of a variety of factors which have shaped the
    development of network components thus far.  The fact that integrity
    checks are assumed to be performed in a network context substantially
    lowers the bar for implementation correctness.
    
    In a storage (or CPU) context, these types of implementation errors
    are a) more easily detectable (more fatal) b) more carefully avoided
    during implementation (because of the cost of a potential fatal
    error).  If network components magically reached the same `quality
    level' as storage and CPU components, there might be no justification
    for additional integrity checks above the transport.  Similarly if the
    transport (or whatever lower layer) integrity checks are very strong
    (e.g. IPSec), there is, again, no need for a higher level integrity
    check.
    
    I am not disagreeing that we need an additional integrity check over
    TCP in the present target environment, but I do disagree that iSCSI
    will always need such a check, independently of what is running
    beneath it.
    
    Steph
    
    
    
    


Home

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