Subject: SCTP checksum problems

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 17 Apr 2001 15:04:23 -0700

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28900
	for <[email-masked]>; Thu, 12 Apr 2001 09:08:59 -0400
(EDT)
[171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28658
	for <[email-masked]>; Thu, 12 Apr 2001 09:00:40 -0400 (EDT)
Date: Thu, 12 Apr 2001 07:59:59 -0500
From: Randall Stewart <[email-masked]>
To: [email-masked]
Subject: [Tsvwg] [Fwd: SCTP checksum problems]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------985277813851A61569C192D4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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
--------------985277813851A61569C192D4
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <[email-masked]>
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com
[171.71.163.10])
	by mira-sjc5-2.cisco.com (Mirapoint)
	with ESMTP id ABO07299;
	Thu, 12 Apr 2001 05:52:03 -0700 (PDT)
by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id FAA18627; Thu,
12 Apr 2001 05:42:46 -0700 (PDT)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 12 Apr 2001 08:42:41 -0400
To: [email-masked]
From: Chip Sharp <[email-masked]>
Subject: SCTP checksum problems
Cc: [email-masked]
In-Reply-To: <LYRIS-1442-559-2001.04.11-18.57.25--chsharp#CISCO.COM@lyri
 s.nortelnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mozilla-Status2: 00000000

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
-------------------------------------------------------------------

--------------985277813851A61569C192D4--

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