Subject: RE: [Tsvwg] RE: U-SCTP comments

From: [email-masked]
Date: Tue, 13 Mar 2001 15:49:37 +0200

See my comments below...

> -----Original Message-----
> From: ext La Monte Henry Piggy Yarroll [mailto:[email-masked]]
> Sent: 13. March 2001 15:35
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Tsvwg] RE: U-SCTP comments 
> 
> 
> [email-masked] writes:
> > > Padding is never counted in the Chunk Length and is never 
> > > covered by the checksum. This is very clear in RFC2960 and U-SCTP
> > > makes no difference here. We can further clarify this by adding a
> > > note.
> > 
> > 	:-O
> > 
> > 	Excuse me Qiaobing, maybe I'm wrong but I couldn't find 
> any place in
> > RFC 2960 that says that the paddings are not included in 
> the checksum :-/...
> > Section 6.8 2) says:
> > 
> >    2) Calculate the Adler-32 checksum of the whole packet, 
> including the
> >       SCTP common header and all the chunks.  Refer to 
> appendix B for
> >       details of the Adler-32 algorithm.  And,
> > 
> > 	Nothing about not including paddings... If you go to 
> the appendix B,
> > you can read:
> > 
> >          while (read_buffer(buffer, length) != EOF) {
> >            adler = update_adler32(adler, buffer, length);
> >          }
> > 
> > 	I guess that buffer is a byte array containing part of 
> the datagram,
> > length is the length of that buffer, and read_buffer reads 
> "length" bytes
> > from the datagram and stores them in "buffer"... It seems 
> that we calculate
> > the checksum of a byte stream (in this case a SCTP 
> datagram) step by step,
> > but everything, even the paddings are included (maybe the 
> one for the last
> > chunk is not??!!).
> > 
> > 	In any case, I haven't modified the Adler-32 checksum 
> algorithm I
> > use in a long time, I include all the bytes of a datagram 
> to calculate it
> > (including all the paddings), and it worked with some other 
> implementations
> > during the bake off, so I guess that other people are doing 
> it as I am...
> 
> I thought this came up at the bakeoff, but I can't find it in
> draft-stewart-ong-sctpbakeoff-sigtran-01.txt.
> 
> There IS a section that clarifies that the padding bytes in the LAST
> bundled chunk are not included in the length of the SCTP packet, so we
> can infer that these should be excluded from the checksum.  Do the
> extra zeros have any effect on the algorithm?

	Well... that is not exactly what we are talking about I guess... I
think that what was stated during the bake off was that the padding of the
last parameter of a chunk wasn't included in the length of that chunk (but
all the rest were included)... I don't remember anything about if the last
padding of the last chunk is included or not in the SCTP packet, since there
isn't any Datagram Length value, just and addition of several Chunk Length
values...

	The extra 0s at the end really change the value of the checksum...
And as I said before, my checksum algorithm was compatible with some other
guy's ones in the bake off (actually all the ones I worked with), so I guess
they were doing the same... I don't see the point of excluding the padding
in the checksum, since in my opinion it doesn't do anything but complicating
more the algorithm, since then you have to parse first the datagram and then
calculating the checksum, and maybe if the checksum is invalid, you can't
even parse the datagram...

	I'm with you if you say that if there is a corruption in one padding
byte, then the whole datagram could be valid and you wouldn't need to
discard it... But I guess that the probability of receiving a corrupted
datagram is low, and even lower is the probability of having that corruption
in one padding byte... I think it is not worthy having extra computation in
every single incoming datagram just to avoid that possibility... you are
going to spend more time skipping padding bytes than if you simply include
them...

	I would appreciate any comments... Thanks!

	BR Iván Arias Rodríguez

	PS: In any case, maybe I'm clumsy but I have looked for any mention
about this in the RFC 2960 and I haven't found any...

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

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Wed, 14 Mar 2001 05:20:03 -0600

Randy and Qiaobing's implementation uses the length value from the IP
header when calculating the checksum.  I.e. the final padding in an
SCTP packet IS covered by the checksum.  I think this counts as
definitive since nearly all existing implementations were validated
against the user space reference.