The IESG has approved the following document: - 'The UDP-Lite Protocol ' <draft-ietf-tsvwg-udp-lite-02.txt> as a Proposed Standard This document is the product of the Transport Area Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document describes the UDP-Lite protocol, which is similar to UDP (RFC 768), but can also serve applications that in error-prone network environments prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP- Lite is semantically identical to UDP. UDP-Lite provides a checksum with optional partial coverage. When using this option, a packet is divided into a sensitive part (covered by the checksum) and an insensitive part (not covered by the checksum). Errors in the insensitive part will not cause the packet to be discarded by the transport layer. Working Group Summary The Transport Working Group supported advancement of this specification. There was Last Call dissent about two aspects: first, its original plan of being a variant of UDP itself. The response was to develop the protocol as a separate transport protocol, which has better properties in general. Second, there were questions about the applicability. For this, the debate was referred to the authors' more detailed conference paper on audio use of errored data. The flexibility of UDP-Lite is not for broad classes of applications, but the conclusion was that it has utility for a significant class of cellular uses now and should be advanced. An additional debate occurred relevant to UDP-lite during IETF 57 during discussion of Aaron Falk's presentation of partial checksum for the IAB plenary: there was mixed support of the value of this general feature in the Internet architecture, but again there were many considerations of applicability. Protocol Quality The protocol was reviewed for the IESG by Allison Mankin and Erik Nordmark. There have been implementations for a number of years and many experimental trials. RFC Editor Notes: 1/ Abstract - Replace "[RFC-768]" with "(RFC 768)" 2/ Security Considerations - Old: Many strong encryption transforms today exhibit this behavior, for reasons obvious from a security point of view. There exist encryption transforms, stream ciphers, which do not spread errors in this way when the damage occurs in the insensitive part of the packet. New: Many encryption transforms today exhibit this behavior. There exist encryptions transforms, stream ciphers, which do not cause error propagation. Note that omitting an integrity check can, under certain circumstances, compromise confidentiality [Bellovin98]. Proper use of stream ciphers poses its own challenges [BB01]. [Bellovin98] Steven M. Bellovin, "Cryptography and the Internet", in Proceedings of CRYPTO '98, August 1998. [BB01] S. Bellovin and M. Blaze, "Cryptographic Modes of Operation for the Internet", Second NIST Workshop on Modes of Operation, August 2001.
