Subject: [Tsvwg] Re: SCTP checksum problems

From: "Lyndon Ong" <[email-masked]>
Date: Thu, 12 Apr 2001 08:48:00 -0700

Better to have figured this out now than later, I guess.  

Lyndon 
--

On Thu, 12 Apr 2001 08:42:41   Chip Sharp wrote:
>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
>-------------------------------------------------------------------
>
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to [email-masked]
>

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

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