Subject: [Tsvwg] RE: SCTP checksum concern

From: "Greg Sidebottom" <[email-masked]>
Date: Thu, 19 Apr 2001 14:35:55 -0400

Hi All,

My recollection of the Sigtran discussions surrounding the addition of the
current checksum are a bit hazy (it has been a while!) so forgive me if I
say something dumb ...

In contrast to the current iSCSI discussions, I don't recall any real
quantitative analysis in the Sigtran group surrounding the addition of the
current SCTP checksum algorithm, determining how strong the checksum
solution had to be to meet the original PSTN signalling transport
requirements.  I remember people generally having a "gut feeling" that a
transport level checksum in SCTP was a good idea and probably required to
meet the SS7 performance requirements - I certainly agreed with this feeling
at the time.  However the choosing of the algorithm was a best effort at
providing the strongest possible solution.  With the information we had at
the time, the end-to-end SCTP 32-bit checksum was arguably better overall
than the link-by-link 16-bit CRC for SS7 MTP networks.

Now that the experts are saying that the current checksum algorithm is not
as strong as we originally thought, at least for some error scenarios, I
still don't see any data that suggests the strength is insufficient for the
PSTN signalling application (i.e., transport of the IUA, M3UA etc.).  As
Lyndon has expressed, "the issue is not that the checksum is "wrong" in the
sense that it causes errors, it's that the checksum does not do a great job
of error detection, esp. in short messages".   To me this is a very
important distinction.  It is also important that any changes to 2960 are
planned to be restricted to the checksum only.

Before anyone flames me, I'll mention that I certainly support the work
going forward in strengthening the checksum solution for SCTP as soon as
possible and issuing a new RFC.  Better now than later.   I just wanted to
express the view that this good work does not imply that the "sky is
falling" or that there is a technical problem for other standards groups
considering adopting the SCTP.   I think the main challenge in standards
fora will be procedural in that standards that are already referencing (or
are considering referencing) the current RFC 2960 and will probably want to
update the SCTP RFC reference - this is not always so easy.   

Cheers,

    Greg

 -----Original Message-----
From: 	Lyndon Ong [mailto:[email-masked]] 
Sent:	Wednesday, April 18, 2001 12:43 PM
To:	sigtran
Subject:	SCTP checksum concern

Folks,

As you may have seen in some of the messages on the list, there is a
developing concern with the SCTP checksum, the Adler 32.  Research has
suggested that the checksum does not perform well for short messages (which,
of course, include most signaling messages).

At this point, the A-Ds are leaning towards flash-cutting SCTP to a
different error check mechanism, so that we would aim to issue a new RFC
replacing 2960, with the new error check.  The format of the messages would
not change, but the processing of the header error check field would
obviously be new and NOT backward compatible with the current processing in
RFC2960.

The argument for flash-cut as opposed to other strategies (e.g., adding
checksum negotiation in a way so as to be backward compatible with RFC2960)
is that actual deployment of SCTP is minimal at this point, and in the long
run it's better to make a clean break now than to add further overhead such
as checksum negotiation.

We still need to go through the process of deciding on what error check
mechanism to use (suggestions have included a modified Adler, a TCP-32 and a
CRC-32).  Since this will be a significant revision to the specification, it
will need to go through WG Last Call and IETF Last Call, although the
changes would be limited to the checksum plus text clarifications, i.e., no
technical changes beyond the checksum.

There will probably be more discussion of this at the bakeoff and on the
lists (esp. you should monitor the TSV WG list as well as the Sigtran list,
some mail has not been going to both lists).  I'll do my best to keep the WG
informed about any developments.

Cheers,

L. Ong

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Thu, 19 Apr 2001 13:48:53 -0500

Greg certainly has a point here. Question: Is SCTP going to go over links
without error detection?
 
Klaus

-----Original Message-----
From: Sidebottom, Greg [BCNR:7M01:EXCH] [mailto:[email-masked]]
Sent: Thursday, April 19, 2001 2:36 PM
To: sigtran
Cc: [email-masked]
Subject: RE: SCTP checksum concern

Hi All, 

Cheers, 

    Greg 

 -----Original Message----- 
From:   Lyndon Ong [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent:   Wednesday, April 18, 2001 12:43 PM 
To:     sigtran 
Subject:        SCTP checksum concern 

Folks, 

Cheers, 

L. Ong 

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

--- 
You are currently subscribed to sigtran as: [email-masked] 
To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

From: Vern Paxson <[email-masked]>
Date: Thu, 19 Apr 2001 12:34:59 PDT

> Greg certainly has a point here. Question: Is SCTP going to go over links

The evidence of the Stone/Partridge checksum study is that the problem
isn't links, it's boxes - routers and end systems. So you want to ensure
you have good protection even if the links themselves have strong protection.
(Basically, the end-to-end principle applied to data integrity.)

		Vern

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