draft-ietf-tsvwg-sctpcsum-06.txt   draft-ietf-tsvwg-sctpcsum-07.txt 
Network Working Group R. Stewart Network Working Group J. Stone
Category: Internet Draft Cisco Systems Category: Internet Draft Stanford
J. Stone R. Stewart
Stanford Cisco Systems
D. Otis D. Otis
SANlight SANlight
April 23, 2002 May 6, 2002
Stream Control Transmission Protocol (SCTP) Checksum Change Stream Control Transmission Protocol (SCTP) Checksum Change
draft-ietf-tsvwg-sctpcsum-06.txt draft-ietf-tsvwg-sctpcsum-07.txt
Status of this Memo Status of this Memo
This document is an internet-draft and is in full conformance with all This document is an internet-draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. Internet- may also distribute working documents as Internet-Drafts. Internet-
Drafts are draft documents valid for a maximum of six months and may be Drafts are draft documents valid for a maximum of six months and may be
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Abstract Abstract
Stream Control Transmission Protocol [RFC2960] (SCTP) currently uses an Stream Control Transmission Protocol [RFC2960] (SCTP) currently uses an
Adler-32 checksum. For small packets Adler-32 provides weak detection Adler-32 checksum. For small packets Adler-32 provides weak detection
of errors. This document changes that checksum and updates SCTP to of errors. This document changes that checksum and updates SCTP to
use a 32 bit CRC checksum. use a 32 bit CRC checksum.
Table of Contents Table of Contents
1 Introduction ................................................1 1 Introduction ................................................1
2 Checksum Procedures .........................................2 2 Checksum Procedures .........................................1
3 Security Considerations......................................6 3 Security Considerations......................................5
4 IANA Considerations..........................................6 4 IANA Considerations..........................................5
5 Acknowledgments .............................................6 5 Acknowledgments .............................................5
6 Authors' Addresses ..........................................6 6 Authors' Addresses ..........................................7
7 References ..................................................7 7 References ..................................................7
8 Appendix ....................................................8 8 Appendix ....................................................7
1 Introduction 1 Introduction
A fundamental weakness has been detected in SCTP's current Adler-32 A fundamental weakness has been detected in SCTP's current Adler-32
checksum algorithm [STONE]. One requirement of an effective checksum is checksum algorithm [STONE]. One requirement of an effective checksum is
that it evenly and smoothly spreads its input packets over the available that it evenly and smoothly spreads its input packets over the available
check bits. check bits.
From an email from Jonathan Stone, who analyzed the Adler-32 as part From an email from Jonathan Stone, who analyzed the Adler-32 as part
of his doctoral thesis: of his doctoral thesis:
skipping to change at page 3, line 43 skipping to change at page 3, line 43
with all '0's and calculate a CRC-32c value of the whole received with all '0's and calculate a CRC-32c value of the whole received
packet. And, packet. And,
3) Verify that the calculated CRC-32c value is the same as the received 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 CRC-32c value. If not, the receiver MUST treat the packet as an
invalid SCTP packet. invalid SCTP packet.
The default procedure for handling invalid SCTP packets is to silently The default procedure for handling invalid SCTP packets is to silently
discard them. discard them.
Any implementation using hardware assists for checksum computation Any hardware implementation SHOULD be done in a way that
MUST make the final CRC value available to the software portion of is verifiable by the sofware.
the stack. Such implementations SHOULD also make the buffer size
used by the hardware unit available to software.
NOTE: this requirement explicitly forbids hardware-acceleration
implementations which provide only a one-bit indication, ``checksum
valid'' or ``checksum invalid'. This requirement is to permit
software to audit the hardware assist: to re-compute the SCTP
checksum over the identical input seen by the outboard hardware
accelerator, and make a comparison of the software-computed and
hardware-assisted values.
This requirement is motivated by experience with a variety of TCP/IP
checksum assists. Bugs in outboard checksum-assist implementations
(which may occur only under certain edge conditions) but which did
not provide the additional information specified here, leave
protocol implementors with little choice but to completely disable
the checksum assist.
An implementation using hardware assist is encouraged to follow the
exact procedure specified above. Whatever implementation strategy
an implementation chooses, it MUST arrange to provide both the
initial value of the checksum field, and the value computed for the
SCTP checksum, to the software stack.
IMPLEMENTATION NOTE: One recommended implementation strategy is:
* save the contents of the checksum field;
* zero out the checksum field;
* compute the checksum;
* the checksum implementation then provides both the
checksum computed over the zeroed-out field, and the initial
value of that zeroed-out field to software.
This strategy is believed to be robust against errors in an
outboard acceleration unit, and against communication errors (or
memory-addressing errors) between an outboard CRC acceleration
unit and the software stack. It also provides a clean path for
retrofitting hardware checksum acceleration into a previously
`software-only' SCTP stack.
We define a 'reflected value' as one that is the opposite of the We define a 'reflected value' as one that is the opposite of the
normal bit order of the machine. The 32 bit CRC is normal bit order of the machine. The 32 bit CRC is
calculated as described for CRC-32c and uses the polynomial code calculated as described for CRC-32c and uses the polynomial code
0x11EDC6F41 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25 0x11EDC6F41 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25
+x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0. +x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0.
The CRC is computed using a procedure similar to ETHERNET CRC [ITU32], The CRC is computed using a procedure similar to ETHERNET CRC [ITU32],
modified to reflect transport level usage. modified to reflect transport level usage.
CRC computation uses polynomial division. A message bit-string M CRC computation uses polynomial division. A message bit-string M
skipping to change at page 5, line 13 skipping to change at page 4, line 28
called `mirrored' or `reflected' [Williams93].) CRC polynomials called `mirrored' or `reflected' [Williams93].) CRC polynomials
are to be transformed back into SCTP transport-level byte values are to be transformed back into SCTP transport-level byte values
using a consistent mapping. using a consistent mapping.
The SCTP transport-level CRC value should be calculated as follows: The SCTP transport-level CRC value should be calculated as follows:
- CRC input data are assumed to a byte stream numbered from 0 - CRC input data are assumed to a byte stream numbered from 0
to N-1. to N-1.
- the transport-level byte-stream is mapped to a polynomial value. - the transport-level byte-stream is mapped to a polynomial value.
An N-byte PDU with bytes 0 to N-1, is considered as An N-byte PDU with bytes 0 to N-1, is considered as
coefficients of a polynomial M(x) of order 8N-1, with coefficients of a polynomial M(x) of order 8N-1, with
bit 0 of byte j being coefficient x^(8j-1), bit 7 of byte bit 0 of byte j being coefficient x^(8(N-j)-8), bit 7 of byte
0 being coefficient x(8j^-8). j being coefficient x^(8(N-j)-1).
- the CRC remainder register is initialized with all 1s - the CRC remainder register is initialized with all 1s
and the CRC is computed with an algorithm that and the CRC is computed with an algorithm that
simultaneously multiplies by x^32 and divides by the CRC simultaneously multiplies by x^32 and divides by the CRC
polynomial. polynomial.
- the polynomial is multiplied by x^32 and divided by G(x), - the polynomial is multiplied by x^32 and divided by G(x),
the generator polynomial, producing a remainder R(x) of degree the generator polynomial, producing a remainder R(x) of degree
less than or equal to 31. less than or equal to 31.
- the coefficients of R(x) are considered a 32 bit sequence. - the coefficients of R(x) are considered a 32 bit sequence.
- the bit sequence is complemented. The resulting is the CRC - the bit sequence is complemented. The resulting is the CRC
polynomial. polynomial.
skipping to change at page 6, line 36 skipping to change at page 5, line 50
4 IANA Considerations 4 IANA Considerations
There are no IANA considerations required in this document. There are no IANA considerations required in this document.
5 Acknowledgments 5 Acknowledgments
The authors would like to thank the following people that have The authors would like to thank the following people that have
provided comments and input on the checksum issue: provided comments and input on the checksum issue:
Mark Adler, Ran Atkinson, Stephen Bailey, David Black, Brian Mark Adler, Ran Atkinson, Stephen Bailey, David Black, Scott
Bidulock, Scott Bradner, Mikael Degermark, Laurent Glaude, Klaus Bradner, Mikael Degermark, Laurent Glaude, Klaus Gradischnig, Alf
Gradischnig, Alf Heidermark, Jacob Heitz, Gareth Kiely, David Heidermark, Jacob Heitz, Gareth Kiely, David Lehmann, Allision
Lehmann, Allision Mankin, Lyndon Ong, Craig Partridge, Vern Paxson, Mankin, Lyndon Ong, Craig Partridge, Vern Paxson, Kacheong Poon,
Kacheong Poon, Michael Ramalho, David Reed, Ian Rytina, Hanns Michael Ramalho, David Reed, Ian Rytina, Hanns Juergen Schwarzbauer,
Juergen Schwarzbauer, Chip Sharp, Bill Sommerfeld, Michael Tuexen, Chip Sharp, Bill Sommerfeld, Michael Tuexen, Jim Williams, Jim Wendt,
Jim Williams, Jim Wendt, Michael Welzl, Jonathan Wood, Lloyd Wood, Michael Welzl, Jonathan Wood, Lloyd Wood, Qiaobing Xie, La Monte
Qiaobing Xie, La Monte Yarroll. Yarroll.
Special thanks to Dafna Scheinwald, Julian Satran Pat Thaler, Matt Special thanks to Dafna Scheinwald, Julian Satran Pat Thaler, Matt
Wakeley, and Vince Cavanna, for selection criteria of polynomials and Wakeley, and Vince Cavanna, for selection criteria of polynomials and
examination of CRC polynomials, particularly CRC-32c [Castagnoli93]. examination of CRC polynomials, particularly CRC-32c [Castagnoli93].
Special thanks to Mr. Ross Williams and his document [Williams93]. Special thanks to Mr. Ross Williams and his document [Williams93].
This non-formal perspective on software aspects of CRCs furthered This non-formal perspective on software aspects of CRCs furthered
understanding of authors previously unfamiliar with CRC computation. understanding of authors previously unfamiliar with CRC computation.
More formal treatments of [Blahut 94] or [Peterson 72], was More formal treatments of [Blahut 94] or [Peterson 72], was
also essential. also essential.
6 Authors' Addresses 6 Authors' Addresses
Randall R. Stewart
24 Burning Bush Trail.
Crystal Lake, IL 60012
USA
EMail: rrs@cisco.com
Jonathan Stone Jonathan Stone
Room 446, Mail code 9040 Room 446, Mail code 9040
Gates building 4A Gates building 4A
Stanford, Ca 94305 Stanford, Ca 94305
EMail: jonathan@dsg.stanford.edu EMail: jonathan@dsg.stanford.edu
Randall R. Stewart
24 Burning Bush Trail.
Crystal Lake, IL 60012
USA
EMail: rrs@cisco.com
Douglas Otis Douglas Otis
800 E. Middlefield 800 E. Middlefield
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email dotis@sanlight.net Email dotis@sanlight.net
7 References 7 References
[Castagnoli93] G. Castagnoli, S. Braeuer and M. Herrman, [Castagnoli93] G. Castagnoli, S. Braeuer and M. Herrman,
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/