Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-04.txt]

From: Randall Stewart <[email-masked]>
Date: Mon, 01 Apr 2002 17:43:41 -0600

Hmm..

Since this did not go to the working group in my reply-all
and my second forward also failed (I think due to anti-spamming)
I will retry.... forwarding to my home email first :>

More comments on the wonderful sctpcsum issue :>

R

Randall Stewart at work wrote:
> 
> I have just looked over the whole thread... and I see both points
> of view on this matter... I must agree Jonathan's arguments are (as
> usual)
> quite persuasive.
> 
> Now another thought I had ...  Where did this wording come from?
> 
> So I went back to RFC2960 and what do I find?
> 
> "
>    When an SCTP packet is received, the receiver MUST first check the
>    Adler-32 checksum:
> 
>    1) Store the received Adler-32 checksum value aside,
> 
> Stewart, et al.             Standards Track                    [Page 82]
> 
> RFC 2960          Stream Control Transmission Protocol      October 2000
> 
>    2) Replace the 32 bits of the checksum field in the received SCTP
>       packet with all '0's and calculate an Adler-32 checksum value of
>       the whole received packet.  And,
> 
>    3) Verify that the calculated Adler-32 checksum is the same as the
>       received Adler-32 checksum.  If not, the receiver MUST treat the
>       packet as an invalid SCTP packet.
> 
>    The default procedure for handling invalid SCTP packets is to
>    silently discard them.
> "
> 
> Looks kind of familiar does it not?
> 
> Now I think (if I have read correctly) what Jonathan has proposed is
> something along
> the lines of:
> 
> "
>     After the packet is constructed (containing the SCTP common header and
>     one or more control or DATA chunks), the transmitter MUST do the
>     following:
> 
>     1) Fill in the proper Verification Tag in the SCTP common header and
>        initialize the Checksum field to 0's.
> 
>     2) Calculate the CRC-32c of the whole packet, including the SCTP common
>        header and all the chunks.
> 
>     3) Put the resultant value into the Checksum field in the common header,
>        and leave the rest of the bits unchanged.
> 
>     When an SCTP packet is received, the receiver MUST perform the checksum
>     algorithm. It SHOULD perform this algorithm using the following procedure:
> 
>     1) Store the received CRC-32c value,
> 
>     2) Replace the 32 bits of the Checksum field in the received SCTP packet
>        with all '0's and calculate a CRC-32c value of the whole received
>        packet.  And,
> 
>     3) Verify that the calculated CRC-32c value is the same as the received
>        CRC-32c value.  If not, the receiver MUST treat the packet as an
>        invalid SCTP packet.
> 
>     A fully conformant SCTP implementation SHOULD use this exact procedure.
> "
> 
> Jonathan: does this capture your AS IF <current> spec sentiment?
> 
> Or did I miss it?
> 
> Would this be acceptable to all concerned? Or am I off base here?
> 
> R
> --
> Randall R. Stewart
> ITD
> Cisco Systems Inc.
> [email-masked] 815-342-5222(cell) or 815-477-2127(office)

Now... I think there are two ways to go.. if this captured
Jonathans idea and the working group agrees... we insert
the above... Or just leave the text as is... I am fine
with either method :>

I have -05 ready with leaving things the way they are...

Comments most welcome :-)

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 3 Apr 2002 04:11:20 -0600

Randall,

Please see comments below...

> >        initialize the Checksum field to 0's.

Do you see the problem with this text????  Why does 1) say to fill in
the proper verification tag and initialize the checksum to 0 when the
paragraph aboves says that the packet already contains an SCTP common
header??  What was in the SCTP common header to begin with?  Random bits?

> >        CRC-32c value.  If not, the receiver MUST treat the packet as an

As Johnathan has not substantiate any of his statements regarding the
exact procedure after several requests for explanation, I propose that
you strike the following sentence and go with the modified text above.

> >     A fully conformant SCTP implementation SHOULD use this exact procedure.

There is no basis for this recommendation.  Another method of calculation
has not been shown to endanger anything, leaving this as an inappropriate
use of SHOULD.  Why use "fully conformant" to try an make the SHOULD a MUST?

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Randall Stewart <[email-masked]>
Date: Wed, 03 Apr 2002 06:56:03 -0600

> header??  What was in the SCTP common header to begin with?  Random bits?

Well lets see if we do NOT have a MUST here I could fill it with
anything I like 32, 64 or maybe 5,260  and still be completely compliant
with the wording. And yes even randon bits would be ok in the common
header if the MUST was not specified...

> you strike the following sentence and go with the modified text above.

Well, so far I have not seen an overwhelming consensus for
change... I will leave this to Scott and Allision to judge. I have
submitted an -05 version with typo's fixed but this left the same
i.e. not the above text that you commented on but the original.

I just don't see it as a problem Phil as convinced me off-line that with
a bit of sideways looking at it even the original wording will allow
Michaels code...

R