Subject: RE: [Tsvwg] sctp error check

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 25 Jun 2001 02:45:19 -0700

Michael,

I really don't like any scheme where the checksum is declared in the
INIT/INIT-ACK. It means you must lookup the association tables before being
able to verify the checksum on a packet. That is a real pain for design IMO

I still believe we should only have one baseline check algorithm for SCTP -
having multiple schemes just tempts laziness on the part of implementers,
leading to interoperability problems - something we don't want for SCTP. 

My vote is still for CRC32 - I don't think that anyone can claim that a
simple summation (no wrapping) for small packets is acceptable. A better
checksum mousetrap (better than TCP and without Adler-32's problems) would
be my first preference but I can't see any concensus being possible on which
(well-known) checksum to use. 

I still think that CRC is the correct choice given that a) we need to move
this forward now and it is the closest thing we have to a consensus and b) a
CRC will at least meet everyone's error requirements for the transport layer
(not necessary end-to-end); c) the performance hit for CRC is not that huge
and d) it is actually much easier to implement in hardware.

We need people to have confidence in SCTP for it to be widely deployed - IMO
this will be hampered if people know that it has a potentially weak checksum
or there are interoperablity problems or it is too difficult to have
hardware-assisted protocol stacks.

Robert.

-----Original Message-----
From:	Tuexen Michael [mailto:[email-masked]]
Sent:	Monday, June 25, 2001 8:05 AM
To:	'Jacob Heitz'; Tuexen Michael
Cc:	[email-masked]
Subject:	RE: [Tsvwg] sctp error check

Dear all,

this describes my feeling...

As I do not see the usage of a per packet change you can use
the INIT/INIT-ACK for setting the checksum algorithm. You could
use a parameter in the INIT/INIT-ACK and can require that this
parameter is the first one. This would mean that you know where
this information is without scanning the whole packet. Please note
that I'm NOT suggesting negotiation here.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CS SE 5    E-mail: [email-masked]

> -----Original Message-----
> From:	Jacob Heitz [SMTP:[email-masked]]
> Sent:	Monday, June 25, 2001 9:00 AM
> To:	Tuexen Michael
> Cc:	[email-masked]
> Subject:	Re: [Tsvwg] sctp error check
> 
> This is what I was afraid of. It's degenerating into a
> heap of good ideas again. Just think, soon we will steal
> 16 bits off the VT for options. Oooh, maybe some for
> header compression, surely SCTP could use some of that.
> Aaaaargh!!!
> 
> Tuexen Michael wrote:
> > 
> > Dear all,
> > 
> > when you say 'stealing away' do you mean:
> > 
> > 1. The highest order two bits describe the checksum for the packet
> > 2. The other 30 bits are the verification tag
> > 
> > This would imply that you could change the checksum algorithm on
> > a per packet base. Is this really needed?
> > 
> > The other possibility is
> > 
> > 1. The highest order two bits describe the checksum for the packet
> > 2. All 32 bits are the verification tag
> > 
> > This would imply that you have to use the same checksum algorithm
> > for all packets of an association.
> > 
> > Thanks for clarification.
> > 
> > Best regards
> > Michael
> > 
> > Michael Tuexen    Tel.:   +49 89 722 47210
> > Siemens AG        Fax:    +49 89 722 48212
> > ICN WN CS SE 5    E-mail: [email-masked]
> > 
> > > -----Original Message-----
> > > From: Douglas Otis [SMTP:[email-masked]]
> > > Sent: Sunday, June 24, 2001 9:49 PM
> > > To:   Jacob Heitz; [email-masked]
> > > Cc:   [email-masked]
> > > Subject:      RE: [Tsvwg] sctp error check
> > >
> > > Jacob,
> > >
> > > Although stealing a few bits away from the verification tag is not as
> > > extensible as a chunk with respect allowing a variation in length, but
two
> > > bits encoded would provide four options.  These four options might
encode
> > > as:
> > >
> > > 0) No Error Check
> > > 1) Simple Error Check
> > > 2) CRC Error Check
> > > 3) Reserved
> > >
> > > Although this offers options that appear as an anathema, doing so with
a
> > > leading chunk of a known type also allows preservation of prior code
and
> > > opens the entire checksum field for future options.  That would be
double
> > > bugger for those left to defend this standard.  The few option flags
used
> > > and the few remaining in TCP have been seen as a means of innovation
for
> > > those wishing change and frustration for those keeping their finger in
the
> > > dyke.  Perhaps to reduce the number of bits and to improve processing
of the
> > > packet, when a special chunk is included, the lower bits of the now
unused
> > > checksum could then indicate the overall length of the packet.  This
would
> > > improve the integrity of error checking in that it would preclude
undetected
> > > truncation.
> > >
> > > If a system was composed of 128 128-Mbit memory chips for total of 2GB
of
> > > memory or 16 chips per side on 4 sticks.  If this system were used as
a
> > > router or firewall, it is possible that staging overwrites the MAC, IP
> > > header and ports in a damaged packet or, if not, this error becomes
limited
> > > to a population of 1 out of a thousand the clients.  It would then be
> > > possible for parsing to detect a damaged packet that would hopefully
be done
> > > prior to acknowledgement where perhaps 25% of those damaged remains
> > > undetected if in the less dynamic upper bits.  If one of these chips
had a> 
> > > weak driver causing half of either ones or zeros to be incorrectly
asserted
> > > perhaps depending on the data pattern and once up to temperature, a
> > > Fletcher-16 error check as example could miss 1% of these errors.
Such a
> > > system would still provided good performance but introduce an
undetected
> > > error once every 50,000 packets if using these simple error checks for
these
> > > unfortunate clients.
> > >
> > > There would be few indications that there was even a problem as most
packets
> > > would be fine.  The link error rate could be negligible and the
software and
> > > other related system hardware could be perfect.  Injected format
errors will
> > > make the transport less robust as parsing is likely beyond
acknowledgement.
> > >
> > > Doug
> > >
> > > > > > I was hoping nobody would say that. Bugger.
> > > > >
> > > > >         The Spanish translation of "bugger" that I read in my
> > > > dictionary is
> > > > > quite "interesting", I imagine you didn't wanted to say the
> > > > first meaning
> > > > > that appears there... :-> I wonder how didn't I manage to learn
> > > > that word
> > > > > before :-)
> > > >
> > > > It is an exclamation of annoyance, like "damn it".
> > > > I meant it in a light hearted way. The dictionary translation looks
> > > > quite offensive. Sorry.
> > >
> > >
> > > _______________________________________________>
> > > tsvwg mailing list
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/tsvwg

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

---

From: [email-masked]
Date: Mon, 25 Jun 2001 14:32:55 +0300

Dear all,

	I think that Jacob's proposal is quite a good chance to finish this
discussion. From my point of view it has the next advantages:

	1.- You can have both Adler-32 checksum and CRC-32, so there are no
worries about which one should be used, both are possible. I don't think we
need more than this, we then would have a "hard and strong" checksum when
using CRC-32 (at least harder when done by software), used for "important"
associations (banks transactions, telephony signaling, medical information,
and who knows what else; and a "quick and less strong" checksum when using
Adler-32, more likely form HTML and the like.
	2.- Even though you use one bit from the Verification Tag, the VT
still has the same use as before. You are not going to change the checksum
scheme during the association, so the VT will always remain the same, and
you can still use the 32 bits of the VT to check the validity of an incoming
datagram.
	3.- The extra information to choose between Adler-32 and CRC-32 is
in the header, so you don't have to keep any memory about which algorithm is
your peer using, you see it as soon as you take a look to bit number 64. No
negotiation at all, nor state keeping or anything. You already know which
algorithm to use for validating the datagram since the very first one (the
one that contains the INIT) of an association.

	And disadvantages:

	1.- It is truth that depending on which checksum you use you already
fix a bit (leaving a "randomness" of "only" 31 bits. But I don't think this
as a big problem.
	2.- When using CRC-32, it won't be backwards compatible.
	3.- You need to provide additional code for CRC-32. Since the code
length won't be more than few lines, I don't see this as a big deal either.
On the other hand, having this since the beginning eliminates
interoperability problems.
	4.- The extra computation cost would be only setting the last bit of
the VT after choosing it (once in the whole life of the association), and a
comparison "if 0 then" for every incoming chunk. This is almost nothing.
	5.- The Verification Tag would carry extra information (I'm not that
sure this is a disadvantage). You can see that last bit of the VT as being
part of it or not...

	Comments? Thank you!

	BR Iván Arias Rodríguez

	PS: If the people don't like this at all, I'm still in the CRC-32
side...

-----Original Message-----
From: ext Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: 25. June 2001 12:45
To: 'Tuexen Michael'
Cc: [email-masked]
Subject: RE: [Tsvwg] sctp error check

Michael,

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 25 Jun 2001 10:30:26 -0400

>Adler-32, more likely form HTML and the like.

        I believe there was stronger consensus that SCTP must not
have more than one checksum than on any other aspect of this
discussion.  So I think the above proposal decreases what little
consensus exists...

        In practice, IETF protocols with more options are 
MUCH less interoperable than those with fewer options.  Having
options on checksums has been an interoperability nightmare with UDP 
for over a decade now in the field.  Please do NOT repeat this 
sort of option in SCTP as we know options relating to checksums 
is a very bad idea.

Ran
[email-masked]

---

From: [email-masked]
Date: Mon, 25 Jun 2001 18:01:37 +0300

Dear Ran,

> sort of option in SCTP as we know options relating to checksums 

	I understand your concerns. But, as far as I know, the
interoperability problems occur when something is optional. This proposal is
not something optional, nor negotiable, it is just a different way of
processing the SCTP packet upon its reception... I don't want either to add
any optional parameter in the INIT/INIT ACK chunks, or having another extra
chunk carrying another checksum... well, "I don't want" means that I just
think that there are better approaches...

	This is not an option at all. It is not even something you have to
keep some memory about. Actually it is kind of a flag (if not completely) in
the datagram header... It would be something maybe even less problematic
than adding the necessary code to receive a SACK with unordered gaps (which
is allowed) and figure out which are the TSNs that should be fast
retransmitted, for example...

	I think we are stopped at some point of the discussion because
people prefer Adler-32 or CRC-32 (or something else). This would give you
the possibility of using one or the other. But in any case, I'm not going to
push anybody... actually after about two months of discussion I think that I
don't care that much which one is used... sick...

	BR Iván Arias Rodríguez

---

From: "Lyndon Ong" <[email-masked]>
Date: Mon, 25 Jun 2001 10:32:03 -0700

Folks,

I think we're kind of barking up the wrong tree in this
discussion, changing the VTag from 32 bits to 31 is a
method for negotiating between different error checks
and we have been trying to avoid this.  Having two 
required error checks is complexity that many folks on
the list have been objecting to.

Can we refocus back to the Adler/CRC discussion?

Cheers,

Lyndon 
--

On Mon, 25 Jun 2001 09:39:59   Jacob Heitz wrote:
>I see nothing in RFC2960 that discusses the reason
>for 32 bits.
>
>Randall Stewart wrote:
>> 
>> Jacob:
>> 
>> I think this issue was answered way back... 32 bits...
>> just have a look at RFC2960 :)
>> 
>> Please do NOT try to solve a problem with the CRC by
>> messing with the other fields...
>> 
>> The one and ONLY concensus that we used to have was
>> that the existing format and useages remain the same
>> EXCEPT the CRC field. I can NOT see messing with other
>> fields... this just spread the chaos around and makes
>> things worse NOT better.
>> 
>> If you want to sacrifise a bit do it from the CRC field
>> itself don't mess with the V-Tag or other fields !!
>> 
>> R
>> 
>> Jacob Heitz wrote:
>> >
>> > So, how many bits do you need ?
>> >
>> > Randall Stewart wrote:
>> > >
>> > > Jacob:
>> > >
>> > > The V-Tag provides a number of nice things. One most notable
>> > > in my mind is the protection against blind attacks. Now if
>> > > you weaken this you open yourself more and more to blind
>> > > attack.
>> > >
>> > > I can much more ask the same question of the CRC. Why not
>> > > put the TCP checksum in, and put the upper 16 bits of
>> > > the current field has flags. Then you get:
>> > >
>> > > A) Current EXACT protection that TCP offers by default.
>> > > B) Ability to have all the flags you want to turn on
>> > >    - trailing checksums
>> > >    - checksum chunks
>> > >    - alternate checksums
>> > >
>> > >
>> > > Make the upper bit of the flags turn on a 31-bit CRC :)
>> > > or anything your heart desires.. but DO NOT mess with the
>> > > V-TAG. You are spreading the proposed problem that Jonathan
>> > > and Craig have put forward into other areas of the protocol.
>> > > Something I can NOT support...
>> > >
>> > > Has I said.. I am almost now leaning into the why should
>> > > we change camp... I understand the mathmatical issue. And
>> > > I have no problem with just adopting CRC-32. But if we are
>> > > going to open up the whole protocol to change.. Forget it
>> > > I drop into the (1) camp.. real fast!
>> > >
>> > > R
>> > >
>> > > Jacob Heitz wrote:
>> > > >
>> > > > How many bits do you REALLY need for the V-Tag and why ?
>> > > > Why is 32 the right number ? Why not maybe 33 ? or 64 ?
>> > > > or 24 ?
>> > > >
>> > > > Randall Stewart wrote:
>> > > > >
>> > > > > Jacob:
>> > > > >
>> > > > > I STRONGLY object to any such thing. If we take this
>> > > > > approach we WEAKEN a KEY defense by removing one bit
>> > > > > of randomness from SCTP.
>> > > > >
>> > > > > This would be a CATASTROPHIC mistake in my mind..
>> > > > >
>> > > > > R
>> > > > >
>> > > > > Jacob Heitz wrote:
>> > > > > >
>> > > > > > The impasse remains. zzzzz.
>> > > > > >
>> > > > > > Another idea:
>> > > > > >
>> > > > > > Sacrifice the high bit of the Verification Tag.
>> > > > > > If it's 0, then Checksum is Adler32
>> > > > > > If it's 1, then Checksum is CRC32
>> > > > > >
>> > > > > > Simple. No extra chunk. No negotiation.
>> > > > > > 31 bits should be enough for the Verification Tag.
>> 
>> --
>> Randall R. Stewart
>> [email-masked] 815-342-5222 (cell phone)
>
>-- 
>// Jacob Heitz Tel:510-747-2917 Ext:72917 Home:510-888-9429
>

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

---

From: [email-masked]
Date: Mon, 25 Jun 2001 21:21:49 +0300

[email-masked] wrote:
> 
> > > Imagine supporting the choice of two checksums, with different
> > > computational cost. The middlebox will always prefer to 
> advertise and
> > > rewrite packets to use the less computationally-expensive 
> checksum, in
> > > order to boost its performance.
> > 
> >         Well, actually the case we are discussing wouldn't 
> allow this...
> > Being part of the VT makes that a change would make the 
> receiver to drop the
> > packet... If you are saying that the routers would discard 
> first the most
> > computationally-expensive packets, then it is another issue...
> 
> If the middle box can re-write anything it wants.. why can it
> not rewrite this bit in the tag area.. remember you are in
> effect changing the meaning of the V-Tag. It is a 31 bit value
> with your proposal (that I MUCH object to). And besides, the
> middle box would also change the Initial-tag as well... remember
> it would tweak with anything it wants!

	Well... in that case you would receive an INIT ACK with the wrong
tag and then you would discard it... I was meaning overloading the use of
one bit of the VT but still counting the 32 bits as part of the VT... so if
you modify it to be able to modify the checksum, the VT would be
different...

[email-masked] wrote:
> The problem for this is, you still need to implement both. Otherwise,
> you end up either completely unprotected or not interoperable 
> with ~half
> of the world.

	Unless you specify it from the beginning... Then of course you will
have to implement both of them (which would mean just some more lines added
to your program...). On the other hand, it means that people expecting to
put CRC on hardware will also need to provide Adler-32 (in software?) as
well... You could always choose the checksum you use but not the one you
receive, so you should only expect that you are going to use your
"preferred" algorithm only in the ones you send... :-/

	But anyway, I think that it is quite clear that people didn't like
it, so... :´-(

	BR Iván Arias Rodríguez

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 25 Jun 2001 15:13:59 -0700

Kacheong,

I thought the only (subjective) consensus we'd reached was that we will only
be having one baseline check algorithm. If so continuing then continuing
this discussion is just drawing focus away from deciding on Randy's straw
poll options! 

It's not like this is a new idea. The suggestions and rationales have
already been brought up on the list. Likewise, we are not trying to rewrite
the SCTP protocol we are trying to make a minimal impact change (or decide
if a change is necessary) to fix a weakness in the current checksum
algorithm for small packets. We need to focus on the three options put
forward by Randall.

Someone please correct me if you think I am out-of-order on this point. 

Robert.

-----Original Message-----
From:	Kacheong Poon [mailto:[email-masked]]
Sent:	Monday, June 25, 2001 10:11 PM
To:	[email-masked]
Subject:	Re: [Tsvwg] sctp error check

> 31 bits should be enough for the Verification Tag.

Can people state their rationale behind having more than 1 checkings
in SCTP?  I really think that we should state the problem before
jumping in a solution.  I guess I am very slow, but I still don't see
the problem at all that leads us to decide that we should have more
than 1 algorithms.

							K. Poon.
							[email-masked]