Subject: [Tsvwg] SCTP and Checksums

From: Randall Stewart <[email-masked]>
Date: Tue, 08 May 2001 09:05:10 -0500

Dear All:

I am not beginning the RFC2960bis work as Lyndon put out. The question
then turns to the checksum. For a first draft of the bis I will
use the Fletcher-16 (its a 32 bit sum.. aka RFC1145). Any pre objections
please raise them ASAP since I am just now beginning the wade through
of the document..

R
-- 
Randall R. Stewart
Systems & Solutions Engineering
Cisco Systems Inc.
[email-masked] 815-342-5222 or 815-477-2127

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: [email-masked]
Date: Fri, 18 May 2001 21:05:40 -0400

Folks,

Since both my name and the IPS WG's reputation
are being slighted on this list, I guess I better
say something, so putting on my flame-resistant
Kevlar armor ...

> At least some of us will object strenuously at IETF Last Call 
> to iSCSI inventing their own security, should it come to that.

For the record, the trend line on the amount of iSCSI
security invention has been headed uniformly down for
a number of months now.  At the moment, the required iSCSI
security will be SRP (RFC 2945) and ESP (RFC 2406).  All
the previous iSCSI-specific digests vanished several
months ago.  The only "invention" contemplated at the
moment is an attempt to figure out how to use SRP to
key ESP so that we can get dynamic keying (and a few
other useful things) without swallowing IKE (which has
been described as requiring 8MB), or reinventing some
large portion of it (which would be a waste of time).

Those who would like to criticize the architecture of
iSCSI ought to bring their comments to the IPS mailing
list, with the awareness that the architecture of IKE is
fair game in the security portion of such a discussion.

As to IPS having the freedom "to do anything out of
the architectural norm they desire", as one of the IPS
chairs, I disagree and observe that the following proposals
have been quashed in IPS:
- Proposals to not use congestion control
- A proposal to invent a new security digest format
- A proposal to invent a new globally unique identifier
	name space
Further discussion of this topic belongs on the IPS
list, not here, please.

> and if David Black's comments are correct, this proposal is about to
> become an Informational RFC.

Depending what was meant by "about to", that may not
be correct.  In the quoted text, "this proposal" refers to
draft-williams-tcpulpframe-01.txt, which is a tsvwg WG work
item, as reflected by this tsvwg charter milestone:

May 01  submit ID on TCP framing by a shim to IESG for
	consideration as a proposed standard

Needless to say, the tcpulpframe draft has yet to be Last Called
in tsvwg (I understand that revisions to it are expected prior to
Last Call), so there will be ample opportunity for further
comment here.  Being publicly criticized over a draft that I
didn't help write and isn't in my WG is a new experience ...

As to the checksum vs. CRC issue, Ran wrote:

>         Common applications don't need the level of protection
> you are advocating.  Specialised applications should not force
> all applications to pay the penalty/costs associated with 
> properties not needed by most applications.  That's part of
> making good engineering tradeoffs in system design.

I respect that position, even though I disagree. 
If tsvwg reaches consensus on that and it is validated
by the IESG, I will respect it and ensure that the
IPS WG respects it.  I do however question the
underlying assumption that no significant applications
other than block storage will ever need the level of
data integrity that SCSI and Fibre Channel have been
providing for years.  Can anyone predict all the
important applications that will use IP in the year 2010?
... I didn't think so (e.g., in 1990 http and the web
would not have been on such a list).

> Use of application-layer extensions for checksums or other
> properties for applications with unusual needs is an accepted 
> part of the Internet Architecture, IMHO.

Even if SCTP requires a CRC, iSCSI will still likely use
its own data CRC to deal with the middle-box issue that
Qiaobing brought up.  As has been noted earlier, iSCSI
can live with SCTP not having a CRC, but it'll result
in what should be one sentence (SCTP retransmit is
sufficient to deal with header corruption issues) being
replaced by several pages of error recovery description.

For those who've had the patience to read this far,
here's one more swipe at the CRC vs. checksum issue:

- Checksums have a tattered record.  The TCP checksum is
	not sufficient, otherwise SCTP would have a 16-bit
	checksum field.  Adler-32 has problems with small
	packets because summing 8-bit quantities into 16-bit
	accumulators yields leading 0 bits when there
	aren't many 8-bit quantities involved.  That
	translates directly to reduced checksum power. 
	Can one be absolutely, positively sure that the
	third checksum choice will be the right one?
	There won't be a fourth chance ...
- SCTP should have one basic data integrity check mechanism,
	whether or not that's a CRC or a checksum.  I tend to
	agree that optional mechanisms won't get implemented
	and will become unusable.  RFC 1146 (TCP Alternate
	Checksum Options) is a worked example.
- The only strong argument I see being made for a checksum is
	based on computational overheads that Moore's law overcomes
	in less than 6 months ... and that's just in the CRC
	code -- measured over the entire SCTP path length, the
	time period would be even shorter.  The same discussion
	also 	characterizes SCTP as being designed for the next
	decade.  Am I the only one who's puzzled by this?
- One could argue that embedded devices don't follow Moore's
	law.  I know of a large class that hasn't - they're
	called "disk drives" and they have no problem with
	doing CRCs :-).  Another example is that I have an
	embedded device on my belt that does both public and
	private key crypto (significantly more expensive in
	cycles than CRCs) - it's called a GSM mobile phone.
	For what class of embedded devices are CRCs an
	unacceptable overhead?

Thanks for reading this far,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------