Subject: [Tsvwg] [Fwd: SCTP checksum problems]

From: Randall Stewart <[email-masked]>
Date: Thu, 12 Apr 2001 07:59:59 -0500

Forwarding to the TSV WG list

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

Subject: SCTP checksum problems
From: Chip Sharp <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 12 Apr 2001 08:42:41 -0400

Lyndon,
It seems that some researchers (Craig Partridge, Jonathan Stone (Stanford), 
Jim Wendt (HP)) have finally gotten around to looking at the SCTP 
checksum... and barfed. :-\
Unfortunately, they didn't do this before the RFC was issued.

The problem with the Adler-32 checksum is that it is noticeably weaker than 
the alternatives for short packets. Of course, since the primary 
application of SCTP is Signaling Transport and call signaling typically 
uses packets less than 128 bytes, this is a major problem.

This problem was basically ferreted out by the iSCSI people.

Randally has already sent an email to the A-Ds.  He inadvertently left you 
off the CC: list.

We currently have a mail thread going with the iSCSI people and with the 
ADs to figure out the best way to approach this.  We have asked the 
researchers to provide us with a better checksum.  Then we have to figure 
out a way to get it into SCTP.  The researchers  so far have proposed 
either a modified Adler-32 using 16 bit accumulator instead of 8 bit, 
Fletcher's checksum or CRC-32.

The methods that we have thought of to migrate to a new checksum:
	1) Obsolete the current SCTP RFC and come out with a new one with the 
modified checksum.  This will fix the problem, but introduces instant 
non-backward compatibility.

	2) Multiple checksum recalculation on INIT.  The transmitter transmits the 
INIT and the receiver tries different checksums until it matches one. This 
has the obvious drawback of increasing the work on the receiver and 
possibly enhancing a DOS.

	3) Checksum negotiation:  We add a new parameter to the INIT to allow the 
endpoints to negotiate the checksum used. The disadvantage of this is that 
it adds complexity to the initialization routine (i.e., deciding when to 
switch over).  The advantage is that it allows for backward compatibility 
and fallback to original SCTP operation and it allows the addition of new 
checksums down the road.

These are the alternatives so far.  We are separating the choice of 
checksum algorithm from the method of negotiating the algorithm since they 
are pretty much orthogonal problems.  Once we get these nailed down we can 
put together a notice to the list, perhaps in the form of an I-D describing 
each method.

This is an unfortunate occurence, but I believe everyone would like to fix 
the checksum as early as possible.  Randall thinks that moving to a 16 bit 
accumulator in the Adler's checksum would be a very easy fix in the code.

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

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 16 Apr 2001 12:28:53 -0500

Another solution could be (I think I mentioned this to Randy and a few
others at last IETF): 

- Define a CRC-32 (or other strong checksum) control chunk and when the
sender wishes to use a stronger checksum protection, in addition to the
Adler-32 in the common SCTP header it includes this CRC-32 chuck in the
outbound packet. When the packet arrives, the receiver will do the
Adler-32 first, and then if the receiver supports the CRC-32 and sees
the presence of the CRC-32 chunk in the packet it will further verify
the CRC-32. 

We could also use a bit pattern in the chunk type of the CRC-32 chunk so
that if the receiver doesn't understand the CRC-32 chunk it would drop
it with a report back to the sender.

-Qiaobing

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

---

From: Randall Stewart <[email-masked]>
Date: Mon, 16 Apr 2001 16:43:57 -0500

Q:

The only problem with an additional "CRC chunk" is that
it makes hardware assistance to error correction much
more difficult. It is better (I think) to just realize
we made a mistake. Get the opinions of the experts as to
what checksum to use... i.e.:

- CRC-32
- Modified Adler-32 (16 bit word sums)
- Fletcher-32
- ???

And then go with this as a replacement... Admit we were wrong
and fix the problem..

This way you have ONE and only ONE checksum algorithm making
hardware designers life much easier...

R