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

From: Randall Stewart at work <[email-masked]>
Date: Mon, 01 Apr 2002 11:12:59 -0600

All:

I just noticed that this did not go to the list...opps...

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

The other choice (that is at least acceptable to me) is to leave
the text alone :>

What is the opinion of the WG??

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

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

---

From: Andreas Jungmaier <[email-masked]>
Date: Thu, 4 Apr 2002 14:04:42 +0200

Randy, dear all,

> What is the opinion of the WG??

I can just speak for myself, but I am perfectly happy with
the text as it is -- and from a practical point of view, there
is a sufficient number of open source implementations and monitoring
tools out there that may be used to test interop with...

This discussion has been sickening for a while, already.... 
get an RFC out !

Best regards,
Andreas
- -- 
- ------------------------------------------------------------------------
Dipl.-Ing. Andreas Jungmaier              |                         _
Computer Networking Technology Group      | ASCII ribbon campaign  ( )
University of Essen                       |  - against HTML email   X
http://www.exp-math.uni-essen.de/~ajung   |              & vcards  / \

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 4 Apr 2002 13:13:32 -0600

Andreas,

Is it our opinion that the current text permits an implementation
to perform the calculation in any mathematically equivalent fashion
or using any meants that acheives the same result?

If so, why are you against saying so in the draft?

--brian

On Thu, 04 Apr 2002, Andreas Jungmaier wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Randy, dear all,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE8rEFaXAsLBNOCSsARAqRrAKCT1HCxBZSnJ2zrQ2wax/Fc97MSlACg9PBJ
> qXlRWGvSofJoYAVGvzSkwK4=
> =IZ/T
> -----END PGP SIGNATURE-----
> 

-- 
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: Andreas Jungmaier <[email-masked]>
Date: Fri, 5 Apr 2002 11:39:41 +0200

> If so, why are you against saying so in the draft?

Oops, 
I believe the busy authors of this draft have already made this
discussion about draft-ietf-tsvwg-sctpcsum-04.txt a thing of the
past....time to read the new draft !

Andreas

---

From: Phillip Conrad <[email-masked]>
Date: Fri, 05 Apr 2002 09:07:04 -0500

>past....time to read the new draft !

I did a diff on 04 vs. 05.   it appears that the only changes in the 05 
version are:
    (1) spelling out SCTP in the title
    (2) typo fix:  s/bit 0 of bit 0/bit 0 of byte 3/
    (3) typo fix: cut and paste error that duplicated some text has been fixed.

So, it is essentially the same draft in terms of content.

I do echo Andreas' earlier sentiment: we need to bring this matter to a 
successful conclusion soon.

Phill