RE: [Tsvwg] [SCTP checksum problems]

[julian_satran@il.ibm.com]

Chip,

CRC s are not meant to protect against malicious middle boxes - rather on
boxes that strip the strong link CRCs and
let the end-system rely on the weak TCP checksum.

NAT boxes have good reason to recompute TCP checksums, but unless they are
malicious no reason to recompute iSCSI CRCs.

And against malicious boxes iSCSI has cryptographic digests as options.

And I was not aware that we are discussing - in this forum - iSCSI data
integrity options.

Julo

Chip Sharp <chsharp@cisco.com> on 19/04/2001 18:53:53

Please respond to Chip Sharp <chsharp@cisco.com>

To:   vince_cavanna@agilent.com
cc:   steph@cs.uchicago.edu, vince_cavanna@agilent.com, jim_wendt@hp.com,
      Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu, tsvwg@ietf.org,
      craig@aland.bbn.com, Jonathan.Wood@sun.com, xieqb@cig.mot.com,
      jonathan@dsg.stanford.edu, rrs@cisco.com
Subject:  RE: [Tsvwg] [SCTP checksum problems]




As was pointed out previously, middle box operations (such as NATs) tend to
creep up the protocol stack and into applications.

Take SIP for example.  It includes IP addresses in its INVITE.  In order to
work across a NAT, the IP addresses it exchanges have to be replaced with
the NATed address.  One way is for the NAT to reach up into the SIP INVITE
and change the address.  This modifies the TCP or UDP checksum.  Now SIP
could have included its own integrity check to protect against corrupted or
modified TCP checksums, but all that would have happened is that NATs would
have changed the SIP checksum in addition to the TCP/UDP checksum.

Therefore, even if iSCSI included its own integrity check, if a middle box
is going to futz with iSCSI packets it will just strip the check, do
whatever it does and then recalculate the check.

If this is what you want to protect against you will have to go to some
type of digital signature.

At 12:22 PM 4/19/2001, vince_cavanna@agilent.com wrote:
>Stephen,
>
>I have to admit that I do not have much direct experience with middle
boxes,
>BUT I did have fairly direct and recent experience with a popular NAT
router
>from a popular vendor that was corrupting data in a network of
Macintoshes.
>
>Apple's TCP was unaware of any problem as was Apple's Filing Protocol and
>most applications. The only applications that detected the corruption were
>those that performed an integrity check of their own. Those applications
>that assumed a reliable transport (and file system) were doomed to
>experiencing the indirect effects of the corruption at some later time.
The
>corruption only happened when large amounts of data were transferred
>quickly.  The router vendor fixed the problem once; then fixed it again;
>then fixed it one last time before the data corruption finally
>"disappeared". After several weeks of continuous operation the router
>appeared to get into a mode where it was once again corrupting data. Power
>cycling the router "fixed it". The story apparently has not yet ended.
>
>I admit I may have given too much significance to this single incident
that
>I have personally experienced but on the other hand I don't see the
>mechanisms in place to prevent this type of problem in the future other
than
>the end to end integrity checks.
>
>Incidentally this incident change my behavior when transferring data over
a
>network. I will always use a compression utility; not only for reducing
the
>data to be transmitted but to ensure the integrity of my data is protected
>end to end by the utility's CRC mechanism.
>
>I believe quite firmly that we DO need a mechanism to allow us to tolerate
>poor implementations of middle boxes and cannot simply hope that
eventually
>such poor implementations will vanish, nor that we will have the luxury of
>being able to select only good implementations for every component of our
>storage network.
>
>Vince
>
>|-----Original Message-----
>|From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
>|Sent: Wednesday, April 18, 2001 3:09 PM
>|To: CAVANNA,VICENTE V (A-Roseville,ex1)
>|Cc: 'WENDT,JIM (HP-Roseville,ex1)'; 'julian_satran@il.ibm.com';
>|ips@ece.cmu.edu; tsvwg@ietf.org; 'Craig Partridge'; Jonathan Wood;
>|xieqb@cig.mot.com; Jonathan Stone; Randall Stewart
>|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
>|


-------------------------------------------------------------------
Chip Sharp                       Consulting Engineering
Cisco Systems
-------------------------------------------------------------------