Subject: [Tsvwg] SCTP Checksum Change to the IESG

From: Scott Bradner <[email-masked]>
Date: Wed, 1 May 2002 08:51:12 -0400 (EDT)

fyi - the revised version of the SCTP checksum chnage will be
posted today as draft-ietf-tsvwg-sctpcsum-06.txt - this is the
version that the IESG will consider for publication as a Proposed
Standard RFC updating RFC 2960.

Scott

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

---

From: Scott Bradner <[email-masked]>
Date: Wed, 1 May 2002 21:42:08 -0400 (EDT)

the twiddeling with this document has gone on far far too long
at this point I do not see a reason to not have the IESG review this
version unless someone can show that it will not work

someday we have to say that its good enough - and that day is now to me

Scott

---

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 1 May 2002 18:34:50 -0700

Scott,

I see the hardware implementation notes added in
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpcsum-06.txt

A check that 'logically' zeros content of the checksum field during a
checksum calculation and then compares the result to an unaltered field is
robust.  Passing an unaltered packet to a software stack provides a complete
diagnostic should there be a suspected problem with checksum hardware and
allows an unmodified software implementation to take over.  It is clumsy to
alter the packet and then require a means to expose this prior value.  Would
it be possible to suggest presenting an unaltered packet in the event of an
error as an alternative?  Exposing the unaltered CRC is common practice as a
diagnostic.  The CRC field in the header over a hidden zero value is an
unusual case with respect to CRC.  Imposing a read/write/read operation on
this field as opposed to just a read is more prone to error and adds
complexity within the circuit and interface.

 -Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 1 May 2002 18:34:50 -0700

Scott,

 -Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 1 May 2002 23:25:46 -0700

Scott,

While I agree with this sentiment, the introduction of a hardware
implementation requirement is new text in conflict with previously raised
concerns.  It appears Jonathan does not agree there is a need to allow
implementations where the packet is not modified during the checking
process.  This is a real problem.  This is true for hardware where an
unmodified packet allows far greater software compatibility and should be
the recommended approach.  I was happy with the draft prior to these last
minute changes that appeared without review.  I was not the one twiddling.
This is a wrong approach, if to standardize the hardware interface as is the
intent of this language.

Presenting an unmodified packet would allow an Alder scheme to be introduced
in software, as example, without any changes to existing code.  The same is
equally true for a software CRC algorithm.  The scheme, as defined now, will
require specialized code to handle such a situation.  The current
recommendation is clumsy and wrong.  More generalized language would be
acceptable such as- For hardware checking schemes, software MUST be able to
confirm the integrity of the packet and not rely exclusively on a status
bit.  An unmodified packet accomplishes this goal.  This added language has
compounded an inappropriate algorithm interpretation.

 -Doug

On May 1, 2002 6:34 PM Douglas Otis ([email-masked]) wrote:
> checksum calculation and then compares the result to an unaltered field
> is robust.  Passing an unaltered packet to a software stack provides
> a complete diagnostic should there be a suspected problem with checksum
> hardware and allows an unmodified software implementation to take over.
> It is clumsy to alter the packet and then require a means to expose this
> prior value.  Would it be possible to suggest presenting an unaltered
> packet in the event of an error as an alternative?  Exposing the
> unaltered CRC is common practice as a diagnostic.  The CRC field in the
> header over a hidden zero value is an unusual case with respect to CRC.
> Imposing a read/write/read operation on this field as opposed to just a
> read is more prone to error and adds complexity within the circuit and
> interface.
>
>  -Doug
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 2 May 2002 03:17:01 -0500

Douglas,

Upon reviewing the draft I agree with your statements.  The added text
makes the draft now presuppose to tell hardware as well as software
designers their business.  It might not be so bad if the recommended
approaches were the obvious best ones, but in both the software and
hardware cases, the strongly recommended and seemingly required
approach is suboptimal.  It further presumes to do this on the grounds
of past faulty hardware design.  I should think that it is obvious
that one would be wise not to purchase or deploy faulty hardware or
software.  No amount of "MUST" and "SHOULD" statements in the draft
will protect against faulty design or faulty implementation either in
software or hardware.  Either faulty hardware or faulty software is
even likely to deliver a faulty packet regardless of the checksum
algorithm.

I don't see a problem with recommending that a hardware assist
function deliver the information necessary to permit the software to
also do the calculation successfully.  But this is an operational
consideration and "MUST" language is IMO inappropriate here.  It is
the business of the hardware designer to either allow for a software
fix to poor hardware design, or not.  These are market issues, not
standardization or interoperability issues.

For software implementations, although the steps which would allow a
proper calculation have been detailed, the draft still does appear to
permit any other algorithm which yields the same result.  Rahter than
allowing software developers to generate optimal algorithms for their
software environment, it appears that the new draft wades into
restricting hardware assist designs also to sub-optimal approaches.

I think that your recommendation for hardware assist to deliver the
packet intact (with original checksum in place) appears to be the best
one for most circumstances and satisfies the objective of permitting
software to also perform the calculation.  It is as suboptimal to
require the hardware to replace the checksum when calculating as it is
to require software to modified a shared buffer.

If the editor of this draft could make the necessary changes to permit
software and hardware designers both to go about their business we
could finalize it and move forward.

I propose that the editor remove the restrictions on software and
hardware design, recommend that the hardware deliver the packet
intact, and only then advance the draft.  Othewise, the draft appears
to be clearly disputable on the grounds of technical error and plain
bad advice.

--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: Thu, 02 May 2002 08:01:12 -0500

> makes the draft now presuppose to tell hardware as well as software

Brian:

I am quite surprised by your comments on software... we did
EXACTLY as you suggested and took the wording back to that
of RFC2960. We did this at YOUR request... I guess you
really were not in agreement with your suggestion.

R

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 2 May 2002 08:53:03 -0500

Randall,

I'm sorry, I didn't notice that.  I suppose I was too busy
reading all the hardware requirements.  If it is back to the
RFC 2960 text, then the software part is done AFAIC.

--brian

---

From: Randall Stewart <[email-masked]>
Date: Thu, 02 May 2002 17:06:22 -0500

Scott/All:

Has I surmised Jonathan is not on the tsvwg list. I have
however spoken to him on the phone and just sent him
this entire thread (up to Pat Thalers last post). 

He is going to digest it and post some responses
to this chain of debate :-)

Now my brief and somewhat limited understanding of his
position is that the Go-Nogo hardware bit is unacceptable
not for when it tells you No-go.. but for when it tells
you GO.

The idea being if it is broken DMA and pulls a bad value
from the packet for the checksum.. checks the packet and
it matches .. it tells you GO.. 

You have no clue in software to re-audit and check it. 

If it returns to you GO and here was the value I used
from the packet to compute it... 

You can, upon seeing the GO compare the value it used
with the packets checksum and if correct.. good.. if bad
you then do the software checksum..

Jonathan will post other details with his reasoning here as
well.. but lets give him some time to digest the 29 or so emails
in this thread :>

Regards

R

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 2 May 2002 16:03:10 -0700

Randall,

Based on that comment, the underlying logic is sound, but we do not agree on
implementation techniques.  Either way, implementation techniques should not
use MUST per RFC 2119.

If the packet is presented unaltered, then software is able to perform
exactly the same checks as if no hardware check existed.

Seeing two values returned and then requiring the host to perform a 32-bit
compare operation is no different than examining a single bit.

The vital requirement is whether software can obtain needed information to
perform the check independent of hardware.  A DMA error may corrupt any
portion of the packet regardless of hardware values presented.  Performing a
read/write/read operation on the packet prior to performing the check
invites an opportunity for errors to be induced.  Should this write
operation step on packet data and miss the checksum field due to a glitch,
then 64 bits of error then exist and may evade detection.  It would seem
this desire to compare values is based on a specific weakness of this
technique and not to capture a DMA error.  This is not a problem if the
packet is not altered.

 -Doug