idnits 2.17.1 draft-ietf-tsvwg-sctpcsum-00.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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 1) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 60 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 114: '... The keywords MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 115: '... SHOULD NOT, RECOMMENDED, NOT RECOM...' RFC 2119 keyword, line 121: '...n section 2.1 of this document MUST be...' RFC 2119 keyword, line 124: '... MUST be treated as a reference to ...' RFC 2119 keyword, line 126: '... that MUST be followed....' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in 'Category: Internet Draft', 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- 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) == Missing Reference: 'RFC2960' is mentioned on line 123, but not defined ** Obsolete undefined reference: RFC 2960 (Obsoleted by RFC 4960) == Missing Reference: 'RFC2119' is mentioned on line 118, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'CRC-32' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Stewart 2 Request for Comments: 2960 C. Sharp 3 Category: Internet Draft Cisco Systems 4 J. Stone 5 Standford 7 June 29 2001 9 SCTP Checksum Change 10 draft-ietf-tsvwg-sctpcsum-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet- Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 SCTP [RFC2960] currently uses an Adler-32 checksum. For small 40 packets, this provides weak protection against the detection of 41 errors. This document changes that checksum and updates SCTP to use 42 the CRC-32 checksum. 44 Table of Contents 46 1. Introduction................................................1 47 1.1 Conventions..............................................2 48 2. Checksum procedures.........................................3 49 2.1 Checksum calculation......................................3 50 3. Acknowledgments.............................................4 51 4. Authors' Addresses..........................................4 52 5. References..................................................4 53 5.1 Normative References......................................4 54 5.2 Informative References....................................4 55 Appendix A Example CRC-32 code.................................5 57 1. Introduction 59 A fundamental weakness has been detected in SCTP's current Adler-32 60 checksum algorithm [STONE]. One requirement of an effective checksum 61 is that it evenly and smoothly spreads its input packets over the 62 available check bits. 64 From an email from Jonathan Stone, who analyzed the Adler-32 as part 65 of his doctoral thesis: 67 "Briefly, the problem is that, for very short packets, Adler32 is 68 guaranteed to give poor coverage of the available bits. Don't take 69 my word for it, ask Mark Adler. :-). 71 Adler-32 uses two 16-bit counters, s1 and s2. s1 is the sum of the 72 input, taken as 8-bit bytes. s2 is a running sum of each value of 73 s1. Both s1 and s2 are computed mod-65521 (the largest prime less 74 than 2^16). Consider a packet of 128 bytes. The *most* that each 75 byte can be is 255. There are only 128 bytes of input, so the 76 greatest value which the s1 accumulator can have is 255 * 128 = 77 32640. So for 128-byte packets, s1 _never_ wraps. That is 78 critical. Why? 80 The key is to consider the distribution of the s1 values, over some 81 distribution of the values of the individual input bytes in each 82 packet. Because s1 never wraps, s1 is simply the sum of the 83 individual input bytes. (even Doug's trick of adding 0x5555 doesn't 84 help here, and an even larger value doesn't really help: we can get 85 at most one mod-565521 reduction). 87 Given the further assumption that the input bytes are drawn 88 independently from some distribution (they probably aren't: for 89 filesystem data, it's even worse than that!), the Central Limit 90 Theorem tells us that that s1 will tend to have a normal 91 distribution. That's bad: it tells us that the value of s1 will 92 have hot-spots at around 128 times the mean of the input 93 distribution: around 16k, assuming a uniform distribution. That's 94 bad. We want the accumulator to wrap as many times as possible, so 95 that the resulting sum has as close to a uniform distribution as 96 possible. (I call this "fairness"). 98 So, for short packets, the Adler-32 s1 sum is guaranteed to be 99 unfair. why is that bad? it's bad because the space of valid 100 packets-- input data, plus checksum values -- is also small. If all 101 packets have checksum values very close to 32640, then the 102 likelihood of even a `small' error leaving a damaged packet with a 103 valid checksum is higher than if all checksum values are equally 104 likely." 106 Due to this inherent weakness, exacerbated by the fact that SCTP will 107 first be used as a signaling transport protocol where signaling 108 messages are usually less than 128 bytes, a new checksum algorithm 109 is specified by this document, replacing the current Adler-32 110 algorithm with CRC-32. 112 1.1 Conventions 114 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 115 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 116 they appear in this document, are to be interpreted as described in 117 [RFC2119]. 119 2. Checksum procedures 121 The procedures described in section 2.1 of this document MUST be 122 followed, replacing the current checksum defined in 123 [RFC2960]. Furthermore any references within [RFC2960] to Adler-32 124 MUST be treated as a reference to CRC-32. Section 2.1 of this 125 document describes the new calculation and verification procedures 126 that MUST be followed. 128 2.1 Checksum calculation 130 When sending an SCTP packet, the endpoint MUST include in the 131 checksum field the CRC-32 [CRC-32] value calculated on the packet, as 132 described below. 134 After the packet is constructed (containing the SCTP common header 135 and one or more control or DATA chunks), the transmitter MUST 136 do the following: 138 1) Fill in the proper Verification Tag in the SCTP common header and 139 initialize the checksum field to 0's. 141 2) Calculate the CRC-32 of the whole packet, including the 142 SCTP common header and all the chunks. 144 3) Put the resultant value into the checksum field in the common 145 header, and leave the rest of the bits unchanged. 147 When an SCTP packet is received, the receiver MUST first perform the 148 following: 150 1) Store the received CRC-32 value, 152 2) Replace the 32 bits of the checksum field in the received SCTP 153 packet with all '0's and calculate a CRC-32 value of 154 the whole received packet. And, 156 3) Verify that the calculated CRC-32 value is the same as the 157 received CRC-32 value. If not, the receiver MUST treat the 158 packet as an invalid SCTP packet. 160 The default procedure for handling invalid SCTP packets is to 161 silently discard them. 163 The CRC-32 is calulated as described in [CRC-32] and uses 164 the polynominal polynomial is (X^32 + X^26 + X^23 + X^22 + X^16 + 165 X^12 + X^11 +X^10 + X^8 + X^7 + X^5 + X^4 + X^2 + X^1 + X^0). 166 Appendix A includes example code that uses a 256 word lookup 167 table. 169 3. Acknowledgments 171 The authors would like to thank the following people that have 172 provided comments and input on the checksum issue: 174 Ran Atkinson, Stephen Bailey, David Black, Scott Bradner, Mikael 175 Degermark, Laurent Glaude, Klaus Gradischnig, Alf Heidermark, Jacob 176 Heitz, Gareth Kiely, David Lehmann, Allision Mankin, Lyndon Ong, 177 Douglas Otis, Craig Partridge, Vern Paxson, Kacheong Poon, Michael 178 Ramalho, David Reed, Ian Rytina, Hanns Juergen Schwarzbauer, Bill 179 Sommerfeld, Michael Tuxen, Jim Williams, Jim Wendt, 180 Michael Welzl, Jonathan Wood, Lloyd Wood, Qiaobing Xie, La Monte 181 Yarroll. 183 4. Authors' Addresses 185 Randall R. Stewart 186 24 Burning Bush Trail. 187 Crystal Lake, IL 60012 188 USA 190 EMail: rrs@cisco.com 192 Chip Sharp 193 Cisco Systems Inc. 194 7025 Kit Creek Road 195 Research Triangle Park, NC 27709 196 USA 198 EMail: chsharp@cisco.com 200 Jonathan Stone 201 Room 446, Mail code 9040 202 Gates building 4A 203 Stanford, Ca 94305 205 EMail: jonathan@dsg.stanford.edu 207 5. References 209 5.1 Normative References 210 [CRC-32] ITU-T Recommendation V.41, "Code-independent 211 error-control system," November 1989. 213 5.2 Informative References 215 [STONE] Doctoral Thesis 217 Appendix A Example CRC-32 code. 219 /* 220 * COPYRIGHT (C) 1986 Gary S. Brown. You may use this program, or 221 * code or tables extracted from it, as desired without restriction. 222 * 223 * First, the polynomial itself and its table of feedback terms. The 224 * polynomial is 225 * X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+X^0 226 * 227 * Note that we take it "backwards" and put the highest-order term in 228 * the lowest-order bit. The X^32 term is "implied"; the LSB is the 229 * X^31 term, etc. The X^0 term (usually shown as "+1") results in 230 * the MSB being 1 231 * 232 * Note that the usual hardware shift register implementation, which 233 * is what we're using (we're merely optimizing it by doing eight-bit 234 * chunks at a time) shifts bits into the lowest-order term. In our 235 * implementation, that means shifting towards the right. Why do we 236 * do it this way? Because the calculated CRC must be transmitted in 237 * order from highest-order term to lowest-order term. UARTs transmit 238 * characters in order from LSB to MSB. By storing the CRC this way 239 * we hand it to the UART in the order low-byte to high-byte; the UART 240 * sends each low-bit to hight-bit; and the result is transmission bit 241 * by bit from highest- to lowest-order term without requiring any bit 242 * shuffling on our part. Reception works similarly 243 * 244 * The feedback terms table consists of 256, 32-bit entries. Notes 245 * 246 * The table can be generated at runtime if desired; code to do so 247 * is shown later. It might not be obvious, but the feedback 248 * terms simply represent the results of eight shift/xor opera 249 * tions for all combinations of data and CRC register values 250 * 251 * The values must be right-shifted by eight bits by the "updcrc 252 * logic; the shift must be unsigned (bring in zeroes). On some 253 * hardware you could probably optimize the shift in assembler by 254 * using byte-swap instructions 255 * polynomial $edb88320 256 */ 258 static unsigned int crc32_tab[] = { 259 0x00000000L, 0x77073096L, 0xee0e612cL, 0x990951baL, 0x076dc419L, 260 0x706af48fL, 0xe963a535L, 0x9e6495a3L, 0x0edb8832L, 0x79dcb8a4L, 261 0xe0d5e91eL, 0x97d2d988L, 0x09b64c2bL, 0x7eb17cbdL, 0xe7b82d07L, 262 0x90bf1d91L, 0x1db71064L, 0x6ab020f2L, 0xf3b97148L, 0x84be41deL, 263 0x1adad47dL, 0x6ddde4ebL, 0xf4d4b551L, 0x83d385c7L, 0x136c9856L, 264 0x646ba8c0L, 0xfd62f97aL, 0x8a65c9ecL, 0x14015c4fL, 0x63066cd9L, 265 0xfa0f3d63L, 0x8d080df5L, 0x3b6e20c8L, 0x4c69105eL, 0xd56041e4L, 266 0xa2677172L, 0x3c03e4d1L, 0x4b04d447L, 0xd20d85fdL, 0xa50ab56bL, 267 0x35b5a8faL, 0x42b2986cL, 0xdbbbc9d6L, 0xacbcf940L, 0x32d86ce3L, 268 0x45df5c75L, 0xdcd60dcfL, 0xabd13d59L, 0x26d930acL, 0x51de003aL, 269 0xc8d75180L, 0xbfd06116L, 0x21b4f4b5L, 0x56b3c423L, 0xcfba9599L, 270 0xb8bda50fL, 0x2802b89eL, 0x5f058808L, 0xc60cd9b2L, 0xb10be924L, 271 0x2f6f7c87L, 0x58684c11L, 0xc1611dabL, 0xb6662d3dL, 0x76dc4190L, 272 0x01db7106L, 0x98d220bcL, 0xefd5102aL, 0x71b18589L, 0x06b6b51fL, 273 0x9fbfe4a5L, 0xe8b8d433L, 0x7807c9a2L, 0x0f00f934L, 0x9609a88eL, 274 0xe10e9818L, 0x7f6a0dbbL, 0x086d3d2dL, 0x91646c97L, 0xe6635c01L, 275 0x6b6b51f4L, 0x1c6c6162L, 0x856530d8L, 0xf262004eL, 0x6c0695edL, 276 0x1b01a57bL, 0x8208f4c1L, 0xf50fc457L, 0x65b0d9c6L, 0x12b7e950L, 277 0x8bbeb8eaL, 0xfcb9887cL, 0x62dd1ddfL, 0x15da2d49L, 0x8cd37cf3L, 278 0xfbd44c65L, 0x4db26158L, 0x3ab551ceL, 0xa3bc0074L, 0xd4bb30e2L, 279 0x4adfa541L, 0x3dd895d7L, 0xa4d1c46dL, 0xd3d6f4fbL, 0x4369e96aL, 280 0x346ed9fcL, 0xad678846L, 0xda60b8d0L, 0x44042d73L, 0x33031de5L, 281 0xaa0a4c5fL, 0xdd0d7cc9L, 0x5005713cL, 0x270241aaL, 0xbe0b1010L, 282 0xc90c2086L, 0x5768b525L, 0x206f85b3L, 0xb966d409L, 0xce61e49fL, 283 0x5edef90eL, 0x29d9c998L, 0xb0d09822L, 0xc7d7a8b4L, 0x59b33d17L, 284 0x2eb40d81L, 0xb7bd5c3bL, 0xc0ba6cadL, 0xedb88320L, 0x9abfb3b6L, 285 0x03b6e20cL, 0x74b1d29aL, 0xead54739L, 0x9dd277afL, 0x04db2615L, 286 0x73dc1683L, 0xe3630b12L, 0x94643b84L, 0x0d6d6a3eL, 0x7a6a5aa8L, 287 0xe40ecf0bL, 0x9309ff9dL, 0x0a00ae27L, 0x7d079eb1L, 0xf00f9344L, 288 0x8708a3d2L, 0x1e01f268L, 0x6906c2feL, 0xf762575dL, 0x806567cbL, 289 0x196c3671L, 0x6e6b06e7L, 0xfed41b76L, 0x89d32be0L, 0x10da7a5aL, 290 0x67dd4accL, 0xf9b9df6fL, 0x8ebeeff9L, 0x17b7be43L, 0x60b08ed5L, 291 0xd6d6a3e8L, 0xa1d1937eL, 0x38d8c2c4L, 0x4fdff252L, 0xd1bb67f1L, 292 0xa6bc5767L, 0x3fb506ddL, 0x48b2364bL, 0xd80d2bdaL, 0xaf0a1b4cL, 293 0x36034af6L, 0x41047a60L, 0xdf60efc3L, 0xa867df55L, 0x316e8eefL, 294 0x4669be79L, 0xcb61b38cL, 0xbc66831aL, 0x256fd2a0L, 0x5268e236L, 295 0xcc0c7795L, 0xbb0b4703L, 0x220216b9L, 0x5505262fL, 0xc5ba3bbeL, 296 0xb2bd0b28L, 0x2bb45a92L, 0x5cb36a04L, 0xc2d7ffa7L, 0xb5d0cf31L, 297 0x2cd99e8bL, 0x5bdeae1dL, 0x9b64c2b0L, 0xec63f226L, 0x756aa39cL, 298 0x026d930aL, 0x9c0906a9L, 0xeb0e363fL, 0x72076785L, 0x05005713L, 299 0x95bf4a82L, 0xe2b87a14L, 0x7bb12baeL, 0x0cb61b38L, 0x92d28e9bL, 300 0xe5d5be0dL, 0x7cdcefb7L, 0x0bdbdf21L, 0x86d3d2d4L, 0xf1d4e242L, 301 0x68ddb3f8L, 0x1fda836eL, 0x81be16cdL, 0xf6b9265bL, 0x6fb077e1L, 302 0x18b74777L, 0x88085ae6L, 0xff0f6a70L, 0x66063bcaL, 0x11010b5cL, 303 0x8f659effL, 0xf862ae69L, 0x616bffd3L, 0x166ccf45L, 0xa00ae278L, 304 0xd70dd2eeL, 0x4e048354L, 0x3903b3c2L, 0xa7672661L, 0xd06016f7L, 305 0x4969474dL, 0x3e6e77dbL, 0xaed16a4aL, 0xd9d65adcL, 0x40df0b66L, 306 0x37d83bf0L, 0xa9bcae53L, 0xdebb9ec5L, 0x47b2cf7fL, 0x30b5ffe9L, 307 0xbdbdf21cL, 0xcabac28aL, 0x53b39330L, 0x24b4a3a6L, 0xbad03605L, 308 0xcdd70693L, 0x54de5729L, 0x23d967bfL, 0xb3667a2eL, 0xc4614ab8L, 309 0x5d681b02L, 0x2a6f2b94L, 0xb40bbe37L, 0xc30c8ea1L, 0x5a05df1bL, 310 0x2d02ef8dL 311 }; 313 /* Return a 32-bit CRC of the contents of the buffer. */ 315 unsigned int 316 ssh_crc32(const unsigned char *s, unsigned int len) 317 { 318 unsigned int i; 319 unsigned int crc32val; 321 crc32val = 0; 322 for (i = 0; i < len; i ++) { 323 crc32val = crc32_tab[(crc32val ^ s[i]) & 0xff] ^ (crc32val >> 8); 324 } 325 return crc32val; 326 } 328 Full Copyright Statement 330 Copyright (C) The Internet Society (2001). All Rights Reserved. 332 This document and translations of it may be copied and furnished to 333 others, and derivative works that comment on or otherwise explain it 334 or assist in its implementation may be prepared, copied, published 335 and distributed, in whole or in part, without restriction of any 336 kind, provided that the above copyright notice and this paragraph are 337 included on all such copies and derivative works. However, this 338 document itself may not be modified in any way, such as by removing 339 the copyright notice or references to the Internet Society or other 340 Internet organizations, except as needed for the purpose of 341 developing Internet standards in which case the procedures for 342 copyrights defined in the Internet Standards process must be 343 followed, or as required to translate it into languages other than 344 English. 346 The limited permissions granted above are perpetual and will not be 347 revoked by the Internet Society or its successors or assigns. 349 This document and the information contained herein is provided on an 350 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 351 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 352 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 353 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 354 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 356 Acknowledgment 358 Funding for the RFC Editor function is currently provided by the 359 Internet Society.