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.