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