datatracker.ietf.org
Sign in
Version 5.4.0, 2014-04-22
Report a bug

Stream Control Transmission Protocol (SCTP) Checksum Change
RFC 3309

Document type: RFC - Proposed Standard (September 2002)
Obsoleted by RFC 4960
Updates RFC 2960
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 3309 (Proposed Standard)
Responsible AD: Allison Mankin
IESG Note: Published: RFC 3309
Send notices to: <mankin@psg.com>, <jon.peterson@neustar.biz>

Network Working Group                                           J. Stone
Request for Comments: 3309                                      Stanford
Updates: 2960                                                 R. Stewart
Category: Standards                                        Cisco Systems
                                                                 D. Otis
                                                                SANlight
                                                          September 2002

      Stream Control Transmission Protocol (SCTP) Checksum Change

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   Stream Control Transmission Protocol (SCTP) currently uses an Adler-
   32 checksum.  For small packets Adler-32 provides weak detection of
   errors.  This document changes that checksum and updates SCTP to use
   a 32 bit CRC checksum.

Table of Contents

   1 Introduction ...................................................  2
   2 Checksum Procedures ............................................  3
   3 Security Considerations.........................................  6
   4 IANA Considerations.............................................  6
   5 Acknowledgments ................................................  6
   6 References .....................................................  7
   Appendix .........................................................  9
   Authors' Addresses ............................................... 16
   Full Copyright Statement ......................................... 17

Stone, et. al.              Standards Track                     [Page 1]
RFC 3309                  SCTP Checksum Change            September 2002

1 Introduction

   A fundamental weakness has been detected in SCTP's current Adler-32
   checksum algorithm [STONE].  This document updates and replaces the
   Adler-32 checksum definition in [RFC 2960].  Note that there is no
   graceful transition mechanism for migrating to the new checksum.
   Implementations are expected to immediately switch to the new
   algorithm; use of the old algorithm is deprecated.

   One requirement of an effective checksum is that it evenly and
   smoothly spreads its input packets over the available check bits.

   From an email from Jonathan Stone, who analyzed the Adler-32 as part
   of his doctoral thesis:

   "Briefly, the problem is that, for very short packets, Adler32 is
   guaranteed to give poor coverage of the available bits.  Don't take
   my word for it, ask Mark Adler.  :-)

   Adler-32 uses two 16-bit counters, s1 and s2.  s1 is the sum of the
   input, taken as 8-bit bytes.  s2 is a running sum of each value of
   s1.  Both s1 and s2 are computed mod-65521 (the largest prime less
   than 2^16).  Consider a packet of 128 bytes.  The *most* that each
   byte can be is 255.  There are only 128 bytes of input, so the
   greatest value which the s1 accumulator can have is 255 * 128 =
   32640.  So, for 128-byte packets, s1 never wraps.  That is critical.
   Why?

   The key is to consider the distribution of the s1 values, over some
   distribution of the values of the individual input bytes in each
   packet.  Because s1 never wraps, s1 is simply the sum of the
   individual input bytes.  (Even Doug's trick of adding 0x5555 doesn't
   help here, and an even larger value doesn't really help: we can get
   at most one mod-65521 reduction.)

   Given the further assumption that the input bytes are drawn
   independently from some distribution (they probably aren't: for file
   system data, it's even worse than that!), the Central Limit Theorem
   tells us that that s1 will tend to have a normal distribution.
   That's bad: it tells us that the value of s1 will have hot-spots at
   around 128 times the mean of the input distribution: around 16k,
   assuming a uniform distribution.  That's bad.  We want the
   accumulator to wrap as many times as possible, so that the resulting
   sum has as close to a uniform distribution as possible.  (I call this
   "fairness".)

Stone, et. al.              Standards Track                     [Page 2]
RFC 3309                  SCTP Checksum Change            September 2002

   So, for short packets, the Adler-32 s1 sum is guaranteed to be
   unfair.  Why is that bad?  It's bad because the space of valid

[include full document text]