Section B. Appendix: Partial Checksumming Design Motivation

A great deal of discussion has taken place regarding the utility of
   allowing a DCCP sender to restrict the checksum so that it does not
   cover the complete packet.  This section attempts to capture some of
   the rationale behind specific details of DCCP design.
   Many of the applications that we envisage using DCCP are resilient to
   some degree of data loss, or they would typically have chosen a
   reliable transport.  Some of these applications may also be resilient
   to data corruption -- some audio payloads, for example.  These
   resilient applications might rather receive corrupted data than have
   DCCP drop corrupted packets.  This is particularly because of
   congestion control: DCCP cannot tell the difference between packets
   dropped due to corruption and packets dropped due to congestion, and
   so it must reduce the transmission rate accordingly.  This response
   may cause the connection to receive less bandwidth than it is due;
   corruption in some networking technologies is independent of, or at
   least not always correlated to, congestion.  Therefore, corrupted
   packets do not need to cause as strong a reduction in transmission
   rate as the congestion response would dictate (as long as the DCCP
   header and options are not corrupt).
   Thus DCCP allows the checksum to cover all of the packet, just the
   DCCP header, or both the DCCP header and some number of bytes from
   the application data.  If the application cannot tolerate any data
   corruption, then the checksum must cover the whole packet.  If the
   application would prefer to tolerate some corruption rather than have
   the packet dropped, then it can set the checksum to cover only part
   of the packet (but always the DCCP header).  In addition, if the
   application wishes to decouple checksumming of the DCCP header from
   checksumming of the application data, it may do so by including the
   Data Checksum option.  This would allow DCCP to discard corrupted
   application data without mistaking the corruption for network
   congestion.
   Thus, from the application point of view, partial checksums seem to
   be a desirable feature.  However, the usefulness of partial checksums
   depends on partially corrupted packets being delivered to the
   receiver.  If the link-layer CRC always discards corrupted packets,
   then this will not happen, and so the usefulness of partial checksums
   would be restricted to corruption that occurred in routers and other
   places not covered by link CRCs.  There does not appear to be
   consensus on how likely it is that future network links that suffer
   significant corruption will not cover the entire packet with a single
   strong CRC.  DCCP makes it possible to tailor such links to the
   application, but it is difficult to predict if this will be
   compelling for future link technologies.
   In addition, partial checksums do not co-exist well with IP-level
   authentication mechanisms such as IPsec AH, which cover the entire
   packet with a cryptographic hash.  Thus, if cryptographic
   authentication mechanisms are required to co-exist with partial
   checksums, the authentication must be carried in the application
   data.  A possible mode of usage would appear to be similar to that of
   Secure RTP.  However, such "application-level" authentication does
   not protect the DCCP option negotiation and state machine from forged
   packets.  An alternative would be to use IPsec ESP, and to use
   encryption to protect the DCCP headers against attack, while using
   the DCCP header validity checks to authenticate that the header is
   from someone who possessed the correct key.  While this is resistant
   to replay (due to the DCCP sequence number), it is not by itself
   resistant to some forms of man-in-the-middle attacks because the
   application data is not tightly coupled to the packet header.  Thus,
   an application-level authentication probably needs to be coupled with
   IPsec ESP or a similar mechanism to provide a reasonably complete
   security solution.  The overhead of such a solution might be
   unacceptable for some applications that would otherwise wish to use
   partial checksums.
   On balance, the authors believe that DCCP partial checksums have the
   potential to enable some future uses that would otherwise be
   difficult.  As the cost and complexity of supporting them is small,
   it seems worth including them at this time.  It remains to be seen
   whether they are useful in practice.
Normative References
   [RFC793]       Postel, J., "Transmission Control Protocol", STD 7,
   [RFC1191]      Mogul, J. and S. Deering, "Path MTU discovery", RFC
                  1191, November 1990.
   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
   [RFC2434]      Narten, T. and H. Alvestrand, "Guidelines for Writing
                  an IANA Considerations Section in RFCs", BCP 26, RFC
                  2434, October 1998.
   [RFC2460]      Deering, S. and R. Hinden, "Internet Protocol, Version
   [RFC3168]      Ramakrishnan, K., Floyd, S., and D. Black, "The
                  Addition of Explicit Congestion Notification (ECN) to
   [RFC3309]      Stone, J., Stewart, R., and D. Otis, "Stream Control
                  Transmission Protocol (SCTP) Checksum Change", RFC
                  3309, September 2002.
   [RFC3692]      Narten, T., "Assigning Experimental and Testing
                  Numbers Considered Useful", BCP 82, RFC 3692, January
                  2004.
   [RFC3775]      Johnson, D., Perkins, C., and J. Arkko, "Mobility
   [RFC3828]      Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.,
                  and G. Fairhurst, "The Lightweight User Datagram
Informative References
   [B98]          Bellovin, S.M., "Cryptography and the Internet",
                  CRYPTO '98 (LNCS 1462), pp 46-55, August 1988.
   [BB01]         Bellovin, S.M. and M. Blaze, "Cryptographic Modes of
                  Operation for the Internet", 2nd NIST Workshop on
                  Modes of Operation, August 2001.
   [M85]          Morris, R.T., "A Weakness in the 4.2BSD Unix TCP/IP
                  Software", Computer Science Technical Report 117, AT&T
                  Bell Laboratories, Murray Hill, NJ, February 1985.
   [PMTUD]        Mathis, M. and J. Heffner, "Path MTU Discovery", Work
                  in Progress, March 2006.
   [RFC792]       Postel, J., "Internet Control Message Protocol", STD
   [RFC1812]      Baker, F., "Requirements for IP Version 4 Routers",
   [RFC1948]      Bellovin, S., "Defending Against Sequence Number
   [RFC1982]      Elz, R. and R. Bush, "Serial Number Arithmetic", RFC
                  1982, August 1996.
   [RFC2018]      Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow,
                  "TCP Selective Acknowledgement Options", RFC 2018,
                  October 1996.
   [RFC2401]      Kent, S. and R. Atkinson, "Security Architecture for
   [RFC2463]      Conta, A. and S. Deering, "Internet Control Message
                  Protocol (ICMPv6) for the Internet Protocol Version 6
   [RFC2581]      Allman, M., Paxson, V., and W. Stevens, "TCP
   [RFC2960]      Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
                  Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
                  Zhang, L., and V. Paxson, "Stream Control Transmission
   [RFC3124]      Balakrishnan, H. and S. Seshan, "The Congestion
   [RFC3360]      Floyd, S., "Inappropriate TCP Resets Considered
   [RFC3448]      Handley, M., Floyd, S., Padhye, J., and J. Widmer,
                  "TCP Friendly Rate Control (TFRC): Protocol
   [RFC3540]      Spring, N., Wetherall, D., and D. Ely, "Robust
                  Explicit Congestion Notification (ECN) Signaling with
   [RFC3550]      Schulzrinne, H., Casner, S., Frederick, R., and V.
                  Jacobson, "RTP: A Transport Protocol for Real-Time
   [RFC3611]      Friedman, T., Caceres, R., and A. Clark, "RTP Control
                  Protocol Extended Reports (RTCP XR)", RFC 3611,
                  November 2003.
   [RFC3711]      Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
                  K. Norrman, "The Secure Real-time Transport Protocol
   [RFC3819]      Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
                  Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J.,
                  and L. Wood, "Advice for Internet Subnetwork
   [RFC4086]      Eastlake, D., 3rd, Schiller, J., and S. Crocker,
                  "Randomness Requirements for Security", BCP 106, RFC
                  4086, June 2005.
   [RFC4341]      Floyd, S. and E. Kohler, "Profile for Datagram
                  Congestion Control Protocol (DCCP) Congestion Control
                  ID 2: TCP-like Congestion Control", RFC 4341, March
                  2006.
   [RFC4342]      Floyd, S., Kohler, E., and J. Padhye, "Profile for
                  Datagram Congestion Control Protocol (DCCP) Congestion
                  Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC
                  4342, March 2006.
   [SHHP00]       Spatscheck, O., Hansen, J.S., Hartman, J.H., and L.L.
                  Peterson, "Optimizing TCP Forwarder Performance",
                  IEEE/ACM Transactions on Networking 8(2):146-157,
                  April 2000.
   [SYNCOOKIES]   Bernstein, D.J., "SYN Cookies",
                  http://cr.yp.to/syncookies.html, as of March 2006.
   [VBK05]        Vanit-Anunchai, S., Billington, J., and T.
                  Kongprakaiwoot, "Discovering Chatter and
                  Incompleteness in the Datagram Congestion Control
                  Protocol", FORTE 2005, pp 143-158, October 2005.
Authors' Addresses
   Eddie Kohler
   4531C Boelter Hall
   UCLA Computer Science Department
   Los Angeles, CA 90095
   USA
   EMail: kohler@cs.ucla.edu
   Mark Handley
   Department of Computer Science
   University College London
   Gower Street
   London WC1E 6BT
   UK
   EMail: M.Handley@cs.ucl.ac.uk
   Sally Floyd
   ICSI Center for Internet Research
   1947 Center Street, Suite 600
   Berkeley, CA 94704
   USA
   EMail: floyd@icir.org
Full Copyright Statement
   Copyright (C) The Internet Society (2006).
   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.
   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.
   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.
   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.
Acknowledgement
   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).