idnits 2.17.1 draft-ietf-tsvwg-sctpcsum-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 67 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([RFC2960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 286 has weird spacing: '...ed long crc_c...' == Line 413 has weird spacing: '...ed long crc_c...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unrecognized Status in '', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 18, 2002) is 8134 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '256' on line 413 == Unused Reference: 'RFC2026' is defined on line 240, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Castagnoli93' -- Possible downref: Non-RFC (?) normative reference: ref. 'McKee75' ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU32' Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Stewart 2 Category: Internet Draft Cisco Systems 3 J. Stone 4 Stanford 5 D. Otis 6 SANlight 8 January 18, 2002 10 SCTP Checksum Change 11 draft-ietf-tsvwg-sctpcsum-02.txt 13 Status of this Memo 15 This document is an internet-draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other groups 20 may also distribute working documents as Internet-Drafts. Internet- 21 Drafts are draft documents valid for a maximum of six months and may be 22 updated, replaced, or obsoleted by other documents at any time. It is 23 inappropriate to use Internet-Drafts as reference material or to cite 24 them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 SCTP [RFC2960] currently uses an Adler-32 checksum. For small packets 33 Adler-32 provides weak detection of errors. This document changes that 34 checksum and updates SCTP to use a 32 bit CRC checksum. 36 Table of Contents 38 1 Introduction ................................................ 1 39 2 Checksum Procedures ......................................... 2 40 3 Security Considerations...................................... 4 41 4 IANA Considerations.......................................... 4 42 5 Acknowledgments ............................................. 4 43 6 Authors' Addresses .......................................... 4 44 7 References .................................................. 5 45 8 Appendix .................................................... 5 47 1 Introduction 49 A fundamental weakness has been detected in SCTP's current Adler-32 50 checksum algorithm [STONE]. One requirement of an effective checksum is 51 that it evenly and smoothly spreads its input packets over the available 52 check bits. 54 From an email from Jonathan Stone, who analyzed the Adler-32 as part 55 of his doctoral thesis: 57 "Briefly, the problem is that, for very short packets, Adler32 is 58 guaranteed to give poor coverage of the available bits. Don't take my 59 word for it, ask Mark Adler. :-). 61 Adler-32 uses two 16-bit counters, s1 and s2. s1 is the sum of the 62 input, taken as 8-bit bytes. s2 is a running sum of each value of s1. 63 Both s1 and s2 are computed mod-65521 (the largest prime less than 2^16). 64 Consider a packet of 128 bytes. The *most* that each byte can be is 255. 65 There are only 128 bytes of input, so the greatest value which the s1 66 accumulator can have is 255 * 128 = 32640. So for 128-byte packets, s1 67 never wraps. That is critical. Why? 69 The key is to consider the distribution of the s1 values, over some 70 distribution of the values of the individual input bytes in each packet. 71 Because s1 never wraps, s1 is simply the sum of the individual input 72 bytes. (even Doug's trick of adding 0x5555 doesn't help here, and an even 73 larger value doesn't really help: we can get at most one mod-65521 74 reduction). 76 Given the further assumption that the input bytes are drawn independently 77 from some distribution (they probably aren't: for file system data, it's 78 even worse than that!), the Central Limit Theorem tells us that that s1 79 will tend to have a normal distribution. That's bad: it tells us that 80 the value of s1 will have hot-spots at around 128 times the mean of the 81 input distribution: around 16k, assuming a uniform distribution. That's 82 bad. We want the accumulator to wrap as many times as possible, so that 83 the resulting sum has as close to a uniform distribution as possible. (I 84 call this "fairness"). 86 So, for short packets, the Adler-32 s1 sum is guaranteed to be unfair. 87 Why is that bad? It's bad because the space of valid packets-- input 88 data, plus checksum values -- is also small. If all packets have 89 checksum values very close to 32640, then the likelihood of even a 90 'small' error leaving a damaged packet with a valid checksum is higher 91 than if all checksum values are equally likely." 93 Due to this inherent weakness, exacerbated by the fact that SCTP will 94 first be used as a signaling transport protocol where signaling messages 95 are usually less than 128 bytes, a new checksum algorithm is specified by 96 this document, replacing the current Adler-32 algorithm with CRC-32c. 98 1.1 Conventions 100 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,SHOULD 101 NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in 102 this document, are to be interpreted as described in [RFC2119]. 104 2 Checksum Procedures 106 The procedures described in section 2.1 of this document MUST be 107 followed, replacing the current checksum defined in [RFC2960]. 108 Furthermore any references within [RFC2960] to Adler-32 MUST be treated 109 as a reference to CRC-32c. Section 2.1 of this document describes the 110 new calculation and verification procedures that MUST be followed. 112 2.1 Checksum Calculation 114 When sending an SCTP packet, the endpoint MUST include in the checksum 115 field the CRC-32c value calculated on the packet, as described below. 117 After the packet is constructed (containing the SCTP common header and 118 one or more control or DATA chunks), the transmitter MUST do the 119 following: 121 1) Fill in the proper Verification Tag in the SCTP common header and 122 initialize the Checksum field to 0's. 124 2) Calculate the CRC-32c of the whole packet, including the SCTP common 125 header and all the chunks. 127 3) Put the resultant value into the Checksum field in the common header, 128 and leave the rest of the bits unchanged. 130 When an SCTP packet is received, the receiver MUST first perform the 131 following: 133 1) Store the received CRC-32c value, 135 2) Replace the 32 bits of the Checksum field in the received SCTP packet 136 with all '0's and calculate a CRC-32c value of the whole received 137 packet. And, 139 3) Verify that the calculated CRC-32c value is the same as the received 140 CRC-32c value. If not, the receiver MUST treat the packet as an 141 invalid SCTP packet. 143 The default procedure for handling invalid SCTP packets is to silently 144 discard them. 146 We define a 'reflected value' as one that is the opposite of the 147 normal bit order of the machine. The 32 bit CRC is 148 calculated as described for CRC-32c and uses the polynomial code 149 0x11EDC6F41 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25 150 +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 with 151 reflected placement. With most serial media, the bits within each 152 byte are shifted out least significant bit first. CRCs are 153 calculated from most significant to least. To accommodate the 154 serial bit order, a reflected table is used. This reflected technique 155 also reduces the number of instructions needed for each lookup. 156 Background information on reflected and non-reflected CRC tables 157 can be found in [Williams93]. A byte based lookup table would 158 use the same shifting algorithm (not the same table) as that 159 used by the ETHERNET CRC [ITU32] since the ethernet CRC is also 160 built with reflected placment. 162 To improve leading zero detection, the working accumulator holding 163 the CRC value is initialized to all one's prior to the packet 164 calculation but is not inverted before being placed in the SCTP 165 Checksum field [McKee75]. Placement in the SCTP common header and jumbo 166 frames cause variances from the Ethernet CRC algorithm. The 167 [Castagnoli93] polynomial offers error detection enhancements for 168 jumbo frames at the expense of gates. The software table 169 implementations for any 32 bit polynomial has the same overhead 170 however. 172 3 Security Considerations 174 There may be a computational advantage in validating the Association 175 against the Verification Tag prior to performing a checksum as 176 invalid tags will result in the same action as a bad checksum in 177 most cases. The exceptions for this technique would be INIT and some 178 SHUTDOWN-COMPLETE exchanges as well as a stale COOKIE-ECHO. These 179 special case exchanges must represent small packets and will 180 minimize the effect of the checksum calculation. In general, 181 the security considerations of RFC2960 apply to the protocol 182 with the new checksum as well. 184 4 IANA Considerations 186 There are no IANA considerations required in this document. 188 5 Acknowledgments 190 The authors would like to thank the following people that have 191 provided comments and input on the checksum issue: 193 Mark Adler, Ran Atkinson, Stephen Bailey, David Black, Scott 194 Bradner, Mikael Degermark, Laurent Glaude, Klaus Gradischnig, Alf 195 Heidermark, Jacob Heitz, Gareth Kiely, David Lehmann, Allision 196 Mankin, Lyndon Ong, Craig Partridge, Vern Paxson, Kacheong Poon, 197 Michael Ramalho, David Reed, Ian Rytina, Hanns Juergen Schwarzbauer, 198 Chip Sharp, Bill Sommerfeld, Michael Tuxen, Jim Williams, Jim Wendt, 199 Michael Welzl, Jonathan Wood, Lloyd Wood, Qiaobing Xie, La Monte 200 Yarroll, Dafna Sheinwald, and Julian Satran, Pat Thaler, Vince 201 Cavanna, Matt Wakeley. 203 Special thanks to Mr. Ross William's and his informative document 204 [Williams93] which helped further the authors understanding of 205 both CRC's and bit reflection. 207 6 Authors' Addresses 209 Randall R. Stewart 210 24 Burning Bush Trail. 211 Crystal Lake, IL 60012 212 USA 214 EMail: rrs@cisco.com 215 Jonathan Stone 216 Room 446, Mail code 9040 217 Gates building 4A 218 Stanford, Ca 94305 220 EMail: jonathan@dsg.stanford.edu 222 Douglas Otis 223 800 E. Middlefield 224 Mountain View, CA 94043 225 USA 227 Email dotis@sanlight.net 229 7 References 231 [Castagnoli93] G. Castagnoli, S. Braeuer and M. Herrman, 232 "Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity 233 Bits", IEEE Transactions on Communications, Vol. 41, No. 6, June 1993 235 [McKee75] H. McKee, "Improved {CRC} techniques detects erroneous 236 leading and trailing 0's in transmitted data blocks", 237 Computer Design Volume 14 Number 10 Pages 102-4,106, 238 October 1975 240 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 241 3", BCP 9, RFC 2026, October 1996. 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, March 1997. 246 [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, 247 H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, 248 and, V. Paxson, "Stream Control Transmission Protocol," RFC 249 2960, October 2000. 251 [ITU32] ITU-T Recommendation V.42, "Error-correcting 252 procedures for DCEs using asynchronous-to-synchronous 253 conversion", section 8.1.1.6.2, October 1996. 255 7.1 Informative References 257 [STONE] Stone, J., "Checksums in the Internet", Doctoral 258 dissertation - August 2001 260 [Williams93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION 261 ALGORITHMS" - Internet publication, August 1993, 262 http://www.geocities.com/SiliconValley/Pines/8659/crc.htm. 264 8 Appendix 266 This appendix is for information only and is NOT part of the 267 standard. The following code is based on the Castagnoli's 268 CRC-32c polynomial 0x11EDC6F41 as in [Castagnoli93] and is 269 not intended to represent an optimal implementation. 271 /*************************************************************/ 272 /* Note Definition for Ross Williams table generatator would */ 273 /* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */ 274 /* For Mr. Williams direct calculation code use the settings */ 275 /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */ 276 /* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */ 277 /*************************************************************/ 279 /* Example of the crc table file */ 280 #ifndef __crc32cr_table_h__ 281 #define __crc32cr_table_h__ 283 #define CRC32C_POLY 0x1EDC6F41 284 #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) 286 unsigned long crc_c[256] = 287 { 288 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, 289 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, 290 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, 291 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, 292 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, 293 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, 294 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, 295 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, 296 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, 297 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, 298 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, 299 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, 300 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L, 301 0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, 302 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, 303 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, 304 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, 305 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, 306 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, 307 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, 308 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, 309 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, 310 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, 311 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, 312 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, 313 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, 314 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, 315 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, 316 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, 317 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, 318 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, 319 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, 320 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, 321 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, 322 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, 323 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, 324 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, 325 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, 326 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, 327 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, 328 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, 329 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, 330 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, 331 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, 332 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, 333 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, 334 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, 335 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, 336 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, 337 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, 338 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, 339 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, 340 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, 341 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, 342 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, 343 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, 344 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, 345 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, 346 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, 347 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, 348 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L, 349 0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, 350 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 351 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L, 352 }; 354 #endif 356 /* Example of table build routine */ 358 #include 359 #include 361 #define OUTPUT_FILE "crc32cr.h" 362 #define CRC32C_POLY 0x1EDC6F41L 363 FILE *tf; 365 unsigned long 366 reflect_32 (unsigned long b) 367 { 368 int i; 369 unsigned long rw = 0L; 371 for (i = 0; i < 32; i++) 372 { 373 if (b & 1) 374 rw |= 1 << (31 - i); 376 b >>= 1; 377 } 378 return (rw); 379 } 381 unsigned long 382 build_crc_table (int index) 383 { 384 int i; 385 unsigned long rb; 387 rb = reflect_32 (index); 389 for (i = 0; i < 8; i++) 390 { 391 if (rb & 0x80000000L) 392 rb = (rb << 1) ^ CRC32C_POLY; 393 else 394 rb <<= 1; 395 } 396 return (reflect_32 (rb)); 397 } 399 main () 400 { 401 int i; 403 printf ("\nGenerating CRC-32c table file <%s>\n", OUTPUT_FILE); 404 if ((tf = fopen (OUTPUT_FILE, "w")) == NULL) 405 { 406 printf ("Unable to open %s\n", OUTPUT_FILE); 407 exit (1); 408 } 409 fprintf (tf, "#ifndef __crc32cr_table_h__\n"); 410 fprintf (tf, "#define __crc32cr_table_h__\n\n"); 411 fprintf (tf, "#define CRC32C_POLY 0x%08lX\n", CRC32C_POLY); 412 fprintf (tf, "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); 413 fprintf (tf, "\nunsigned long crc_c[256] =\n{\n"); 414 for (i = 0; i < 256; i++) 415 { 416 fprintf (tf, "0x%08lXL, ", build_crc_table (i)); 417 if ((i & 3) == 3) 418 fprintf (tf, "\n"); 419 } 421 fprintf (tf, "};\n\n#endif\n"); 423 if (fclose (tf) != 0) 424 printf ("Unable to close <%s>." OUTPUT_FILE); 425 else 426 printf ("\nThe CRC-32c table has been written to <%s>.\n", 427 OUTPUT_FILE); 428 } 429 /* Example of crc insertion */ 431 #include "crc32cr.h" 433 int 434 insert_crc32(unsigned char *buffer, unsigned int length) 435 { 436 SCTP_message *message; 437 unsigned int i; 438 unsigned long crc32 = ~0L; 440 /* check packet length */ 441 if (length > NMAX || length < NMIN) 442 return -1; 444 message = (SCTP_message *) buffer; 445 message->common_header.checksum = 0L; 447 for (i = 0; i < length; i++) 448 { 449 CRC32C(crc32, buffer[i]); 450 } 452 /* and insert it into the message */ 453 message->common_header.checksum = htonl(crc32); 454 return 1; 455 } 457 /* Example of crc validation */ 458 /* Test of 32 zeros should yield 0x756EC955 placed in network order */ 459 /* 13 zeros followed by byte values of 1 - 0x1f should yield 460 /* 0x5b988D47 */ 462 int 463 validate_crc32(unsigned char *buffer, unsigned int length) 464 { 465 SCTP_message *message; 466 unsigned int i; 467 unsigned long original_crc32; 468 unsigned long crc32 = ~0L; 470 /* check packet length */ 471 if (length > NMAX || length < NMIN) 472 return -1; 474 /* save and zero checksum */ 475 message = (SCTP_message *) buffer; 476 original_crc32 = ntohl(message->common_header.checksum); 477 message->common_header.checksum = 0L; 479 for (i = 0; i < length; i++) 480 { 481 CRC32C(crc32, buffer[i]); 482 } 484 return ((original_crc32 == crc32)? 1 : -1); 485 } 487 Full Copyright Statement 489 Copyright (C) The Internet Society (2001). All Rights Reserved. 491 This document and translations of it may be copied and furnished to 492 others, and derivative works that comment on or otherwise explain it or 493 assist in its implementation may be prepared, copied, published and 494 distributed, in whole or in part, without restriction of any kind, 495 provided that the above copyright notice and this paragraph are included 496 on all such copies and derivative works. However, this document itself 497 may not be modified in any way, such as by removing the copyright notice 498 or references to the Internet Society or other Internet organizations, 499 except as needed for the purpose of developing Internet standards in 500 which case the procedures for copyrights defined in the Internet 501 Standards process must be followed, or as required to translate it into 502 languages other than English. 504 The limited permissions granted above are perpetual and will not be 505 revoked by the Internet Society or its successors or assigns. 507 This document and the information contained herein is provided on an "AS 508 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 509 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 510 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 511 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 512 FITNESS FOR A PARTICULAR PURPOSE. 514 Funding for the RFC Editor function is currently provided by the 515 Internet Society.