INTERNET-DRAFT Lars-AkeNetwork Working Group L-A. Larzon TSV WGINTERNET-DRAFT Lulea University of Technology, Sweden January 24, 2002 Mikael DegermarkTechnology Expires: July 24, 2002 StephenJune 2003 M. Degermark S. Pink The University of Arizona, USAArizona L-E. Jonsson (editor) Ericsson G. Fairhurst (editor) University of Aberdeen December 5, 2002 The UDP LiteUDP-Lite Protocol <draft-ietf-tsvwg-udp-lite-00.txt><draft-ietf-tsvwg-udp-lite-01.txt> Status of this Memomemo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC-2026]. This document is an Internet-Draft.RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or tocite them other than as ``work"work in progress.''progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txthttp://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.http://www.ietf.org/shadow.html Please direct comments to the TSV WG mailing list: firstname.lastname@example.org Abstract This document describes the UDP LiteUDP-Lite protocol, which is similar to classicUDP [RFC-768], but can also serve applications whichthat in lossyerror-prone network environments prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDPUDP- Lite is semantically identical to classicUDP. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. Protocol Description...........................................3 3.1. Fields....................................................3 3.2. Pseudo Header.............................................4 3.3. Application Interface.....................................4 3.4. IP Interface..............................................5 3.5. Jumbograms................................................5 4. Lower Layer Considerations.....................................5 5. Compatibility with UDP.........................................6 6. Security Considerations........................................7 7. IANA Considerations............................................7 8. References.....................................................8 8.1. Normative References......................................8 8.2. Informative References....................................8 9. Acknowledgements...............................................8 10. Authors' Addresses............................................9 1. Introduction Why another transport protocol? First, there is a class of applications whichthat prefer to have damaged data delivered rather than discarded by the network. A number of codecs for voice and video fall into this class. These codecs are designed to cope better with errors in the payload than with loss of entire packets. Second, there are a number of link technologies where data can be partially damaged. Several radio technologies exhibit this behavior when operating at a point where cost and delay isare sufficiently low. Third, intermediate layers should not prevent sucherror-tolerant applications to run well overin the presence of such links. The intermediate layers are IP and the transport layer. IP is not a problem in this regard since the IP header has no checksum whichthat covers the IP payload. The generally available transport protocol best suited for these applications is UDP, since it has no overhead for retransmission of erroneous packets, in-order deliverydelivery, or error correction. However,In IPv4 [RFC-791], the UDP checksum eithercovers either the entire datagrampacket or nothing at all. Moreover, in the next version of IP,In IPv6 [RFC-2460], the UDP checksum is mandatory and must not be disabled. The IPv6 header does not have a header checksum and it was deemed necessary to always protect the IP addressing information by making the UDP checksum mandatory. A transport protocol is needed that conforms withto the properties of link layers and applications described above.above [UDP-LITE]. The error-detectionerror- detection mechanism of the transport layer must be able to protect vital information such as headers, but also to optionally ignore errors best dealt with by the application. What should be verified by the checksum is best specified by the sending application. UDP LiteUDP-Lite provides a checksum with optionallyan optional partial coverage. When using this option, a datagrampacket 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 datagrampacket to be discarded.discarded by the transport layer at the receiving end host. When the checksum covers the entire datagram,packet, which SHOULDshould be the default, UDP LiteUDP-Lite is semantically identical to UDP. Compared to UDP (hereafter referred to as "classic UDP"),UDP, the UDP-Lite partial checksum provides extra flexibility for applications withthat want to define the payload as partially insensitive data.to bit errors. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 3. Protocol descriptionDescription The UDP LiteUDP-Lite header is shown in figure 1. Its format differs from classicUDP in that the Length field has been replaced with a Checksum Coverage field. This can be done since information about UDP packet length can be provided by the IP module in the same manner as for TCP [rfc-793].[RFC-793]. 0 15 16 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | Checksum | | | Coverage | Checksum | +--------+--------+--------+--------+ | | : Payload : | data bytes ...| +---------------- ...---------------++-----------------------------------+ Figure 1: New UDPUDP-Lite Header Format 3.1. Fields The fields ``Source Port''Source Port and ``Destination port''Destination Port are defined as in the UDP specification [RFC-768]. UDP-Lite uses the same set of port number values as those assigned by the IANA for use by UDP. Checksum Coverage is the number of bytes,octets, counting from the first byteoctet of the new UDPUDP-Lite header, that are covered by the checksum. The UDP LiteUDP-Lite header MUST always be included incovered by the checksum. Despite this requirement, the Checksum Coverage is expressed in bytesoctets from the beginning of the UDP Lite headerUDP-Lite header, in order to preserve compatibility with classicthe same way as for UDP. A Checksum Coverage of zero indicates that the entire new UDPUDP-Lite packet is included incovered by the checksum. This means that the value of the Checksum Coverage field MUST be either zero0 or at least eight.8. A UDP-Lite packet with a Checksum Coverage value of 1 to 7 MUST be discarded by the receiver. UDP-Lite packets with a Checksum Coverage greater than the IP length MUST also be discarded. Checksum is the 16-bit one's complement of the one's complement sum of a pseudo-header of information from the IP header, the number of bytesoctets specified by the Checksum Coverage (starting at the first byteoctet in the new UDPUDP-Lite header), virtually padded with a zero bytesoctet at the end (if necessary) to make a multiple of two bytes.octets [RFC-1071]. If the computed checksum is zero,0, it is transmitted as all ones (the equivalent in one's complement arithmetic). The transmitted checksum MUST NOT be all zeroes. Pseudo header SimilarIf an application using UDP-Lite wishes to classic UDP, UDP Lite uses a conceptually prefixed pseudohave no protection of the packet payload, it should use a Checksum Coverage value of 8. This differs from the use of UDP over IPv4, in that the minimal UDP-Lite checksum always covers the UDP-Lite protocol header, which includes the Checksum Coverage field. 3.2. Pseudo Header UDP and UDP-Lite use the same conceptually prefixed pseudo header from the IP layer for checksumming purposes. The format ofthe checksum. This pseudo header is the same asdifferent for classic UDP,IPv4 and differs for different versions of IP.IPv6. The pseudo header of UDP LiteUDP-Lite is different from the pseudo header of classicUDP in one way: The value of the lengthLength field of the pseudo header is not taken from the UDP LiteUDP-Lite header, but rather from information provided by the IP module. This computation is done in the same manner as for TCP [RFC-793], and implies that the lengthLength field of the pseudo header includes the UDP LiteUDP-Lite header and all subsequent bytesoctets in the IP payload. User3.3. Application Interface A userAn application interface should allow the same operations as for classicUDP. In addition to this, it SHOULDshould provide a way for the sending application to pass the checksum coverage value to the UDP LiteUDP-Lite module. There SHOULDshould also be a way to pass the checksum coverage value to the receiving application, or at least let the receiving application block delivery of packets with coverage values less than a value provided by the application. We RECOMMENDIt is RECOMMENDED that the default behaviourbehavior of UDP Lite isUDP-Lite be to mimic classicUDP by having the coverageChecksum Coverage field match the length of the UDP Lite datagramUDP-Lite packet, and verifyingverify the entire packet. Applications that want to define the payload as partially insensitive to bit errors SHOULD(e.g. error tolerant codecs using RTP [RFC-1889]) should do that by a separatean explicit system call on the sender side. Applications that wish to receive payloads whichthat were only partially covered by a checksum SHOULDshould inform the receiving system by a separatean explicit system call. The characteristics of the links forming an Internet path may vary greatly. It is therefore difficult to make assumptions about the level or patterns of errors that may occur in the insensitive part of the UDP-Lite payload. Applications that use UDP-Lite should not make any assumptions regarding the correctness of the received data beyond the indicated checksum coverage, and should if necessary introduce their own appropriate validity checks. 3.4. IP Interface As for classicUDP, the UDP LiteIP module must passprovide the pseudo header to the UDPUDP- Lite module. The UDP LiteUDP-Lite pseudo header contains the IP addresses and protocol fields of the IP header, and also the length of the IP payloadpayload, which is derived from the lengthLength field of the IP header. The sender IP module MUST NOT pad the IP payload with extra bytesoctets since the length of the UDP LiteUDP-Lite payload delivered to the receiver depends on the length of the IP payload. 3.5. Jumbograms The Checksum Coverage field is 16 bits and can represent a checksum coverage of up to 65535 octets. This allows arbitrary checksum coverage for IP packets, unless they are Jumbograms. For Jumbograms, the checksum can cover either the entire payload (when the Checksum Coverage field has the value zero), or else at most the initial 65535 octets of the UDP-Lite packet. 4. Lower layer considerationsLayer Considerations Since UDP LiteUDP-Lite can deliver packets with damaged payloads to an application that wants them, frames carrying UDP LiteUDP-Lite packets need not be discarded by lower layers when there are errors only in the insensitive part. For a link layerthat supports partial error detection, the Checksum Coverage field in the UDP LiteUDP-Lite header MAY be used as a hint of where errors shoulddo not need to be detected. LinkLower layers that do not support partial checksums SHOULDMUST use a strong error detection mechanism to detect errors in the entire frame. In general, lower layers SHOULD detect errorsat least errors that occur in the sensitive part of the frame using strong error detection mechanisms, but need not do so forpacket, and discard damaged packets. The sensitive part consists of the insensitive part. Note that it is usually only over links where errors are frequent thatoctets between the partial checksum featurefirst octet of UDP Lite can make a difference tothe application. On links where errors are infrequent it is RECOMMENDEDIP header and the last octet identified by the Checksum Coverage field. At least the sensitive part would thus be treated in exactly the same way as UDP packets. Link layers that lower layeersdo not support partial error detection suitable for UDP-Lite, as described above, MUST detect errors in the entire packet. JumbogramsUDP- Lite packet, and discard damaged packets. The Checksum Coverage fieldwhole UDP-Lite packet is 16 bits and can represent checksum coverage up to 65535 octets. This allows arbitrary checksum coverage for IP datagrams, unless they are Jumbograms. For Jumbograms, the Checksum can cover either the entire payload (whenthus treated in exactly the Checksum Coverage field hassame way as a UDP packet. It should be noted that UDP-Lite would only make a difference to the value zero), or else at mostapplication if partial error detection, based on the initial 65535 octetspartial checksum feature of UDP-Lite, is implemented also by link layers, as discussed above. Obviously, partial error detection at the link layer would only make a difference when implemented over error-prone links. 5. Compatibility with UDP Lite datagram. Backwards compatibility The syntactic and semantic similarity betweenUDP Liteand classicUDP-Lite have similar syntax and semantics. Applications designed for UDP suggests that they might sharemay therefore use UDP-Lite instead, and will by default receive the same full packet coverage. The similarities also ease implementation of UDP-Lite, since only minor modifications are needed to an existing UDP implementation. UDP-Lite has been allocated a separate IP protocol identifier.identifier, XXXX [INSERT IANA NUMBER BEFORE PUBLICATION], that allows a receiver to identify whether UDP or UDP-Lite is used. A system unaware of UDP- Lite will in general return an ICMP Protocol Unreachable error message to the sender. This section explores some consequencessimple method of doing so.detecting UDP-Lite unaware systems is the primary benefit of having separate protocol identifiers. The remainder of this section provides the rationale for allocating a separate IP protocol identifier for UDP-Lite, rather than sharing the IP protocol identifier with UDP. There are no known interoperability problems between classicUDP and UDP LiteUDP-Lite if they were to share the protocol identifier of classicwith UDP. To be more precise:Specifically, there is no case where a potentially problematic packet is delivered to an unsuspecting application; a UDP LiteUDP-Lite payload with partial checksum coverage cannot be delivered to UDP applications, and UDP datagrams whichpackets that only partially fillsfill the IP payload cannot be delivered to UDP Lite applications. Ifapplications using UDP-Lite. However, if the protocol identifier waswere to be shared between UDP and UDP LiteUDP-Lite, and a UDP LiteUDP-Lite implementation sends UDP Lite packets withwas to send a UDP-Lite packet using a partial checksumschecksum to a classicUDP implementation, the classicUDP implementation would silently discard themthe packet, because a mismatching pseudo header would cause the UDP checksum to mismatch.fail. Neither the sending nor the receiving application would be notified. The obviousPotential solutions to this includecould have been: 1) explicit application in-band signaling (not(while not using the partial checksum coverage option) to enable the sender to learn whether the receiver is UDP LiteUDP-Lite enabled or not, or 2) use of out-of-band signaling such as H.323, SIP, or RTCP to convey whether the receiver is UDP Lite enabled. If UDP Lite has its own separate protocol identifier, on the other hand, a system unaware of UDP Lite would return ICMP Protocol Unreachable error messages to the sender. This simple method of detecting UDP Lite unaware systems is the primary benefit of having separate protocol identifiers. Therefore, this draft proposes to allocate a new protocol identifier for UDP Lite. Security considerations The security impact of UDP Lite is twofold. First, applications who do not expect damaged payloads are bound to malfunction if damaged payloads are delivered to them. To avoid this, we RECOMMEND that the sending and the receiving side application both explicitly enable the partial checksum option. Packets with partial checksums SHOULD NOT be deliveredof out-of-band signaling such as H.323, SIP, or RTCP to applications that have not enabledconvey whether the partial checksum option. Second,receiver is UDP-Lite enabled. Anyway, since UDP-Lite has now been assigned its own protocol identifier, there is no need to consider the questionpossibility of howdelivery of a UDP-Lite packet to an unsuspecting UDP Lite interactsport. 6. Security Considerations The security impact of UDP-Lite is related to its interaction with authentication and encryption mechanisms. When the partial checksum option of UDP LiteUDP-Lite is enabled, it is fine with the application ifthe insensitive partportion of a packet changesmay change in transit. This is contrary to the idea behind most authentication mechanisms;mechanisms: authentication succeeds whenif the packet has not changed in transit. Unless authentication mechanisms that operate only on the sensitive part of packets are developed,developed and used, authentication will always fail on UDP LiteUDP-Lite packets where the insensitive part has been damaged. The IPSec integrity check (Encapsulation Security Protocol, ESP, or Authentication Header, AH) is applied (at least) to the entire IP packet payload. Corruption of any bit within the protected area will then result in the discarding of the UDP-Lite packet by the IP receiver. Encryption is also an issue when using UDP Lite.UDP-Lite. If a few bits of an encrypted packet are damaged, the decryption transform will typically spread this errorerrors so that the packet becomes too damaged to be of use. MostMany strong encryption transforms today exhibit this behaviour,behavior, for good reason. It might be possible to developreasons obvious from a security point of view. There exist encryption transformstransforms, stream ciphers, which woulddo not spread damageerrors in this way when the damage occurs in the insensitive part of the packet. A class of such transforms would be transforms where the sensitive part is encrypted using a strong transform as usual, and the insensitive part is encrypted by XORing it with a cryptographic hash computed over the cleartext of the sensitive part. However, it is clear that with most transforms in use today, encryption eliminates the benefits that the partial checksum coverage option of the UDP Lite might bring.7. IANA considerations We request that aConsiderations A new ipIP protocol identifier is allocatednumber, XXXX [INSERT NUMBER BEFORE PUBLICATION], has been assigned for UDP Lite. Conclusions We have presented the UDP Lite protocol.UDP-Lite. [NOTE, REMOVE BEFORE PUBLICATION] IANA assignment instruction: - The main motivationIANA must reserve an IP protocol number for this new variant ofUDP-Lite. [END OF NOTE] 8. References 8.1. Normative References [RFC-768] Postel, J., "User Datagram Protocol", RFC 768 (STD6), August 1980. [RFC-791] Postel, J., "Internet Protocol", RFC 791 (STD5), September 1981. [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793 (STD7), September 1981. [RFC-1071] Braden, R., Borman, D., and C. Partridge, "Computing the classic UDP transport protocol is decreased packet error ratesInternet Checksum", RFC 1071, September 1988. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119 (BCP15), March 1997. [RFC-2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 8.2. Informative References [RFC-1889] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for damage-tolerant applications today using classic UDP in harsh network environments. UDP Lite provides optionally partial checksum coverage which increases the flexibility of classic UDP by making it possibleReal-Time Applications", RFC 1889, January 1996. [RFC-2026] Bradner, S., "The Internet Standards Process", RFC 2026, October 1996. [RFC-2402] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC-2406] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 206, November 1998. [UDP-LITE] Larzon, L-A., Degermark, M., and S. Pink, "UDP Lite for Real-Time Multimedia Applications", Proceedings of the IEEE International Conference of Communications (ICC), 1999. 9. Acknowledgements Thanks to Ghyslain Pelletier for significant technical and editorial comments. Thanks also to define a packet as partially insensitiveElisabetta Carrara and Mats Naslund for reviewing the security considerations chapter, and to bit errors onPeter Eriksson for doing a per-packet basis. If no partlanguage review and thereby improving the clarity of a packet is defined as insensitive, UDP Lite is semantically identical to classic UDP. Contact infothis document. 10. Authors' Addresses Lars-Ake Larzon Department of CS & EE Lulea University of Technology S-971 87 Lulea, Sweden Email: email@example.com Mikael Degermark Department of Computer Science The University of Arizona P.O. Box 210077 Tucson, AZ 85721-007785721-0077, USA Email: firstname.lastname@example.org Stephen Pink The University of Arizona P.O. Box 210077 Tucson, AZ 85721-007785721-0077, USA Email: email@example.com Normative References [RFC-768] Postel, J., "User Datagram Protocol," RFC 768, Information Sciences Institute, August 1980. [RFC-793] Postel, J., "Transmission Control Protocol," RFC 793, Information Sciences Institute, September 1981. [RFC-2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification," RFC 2460, IETF, December 1998. Informative References [RFC-2026] Bradner, S., "TheLars-Erik Jonsson Ericsson AB Box 920 S-971 28 Lulea, Sweden Email: firstname.lastname@example.org Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE, UK Email: email@example.com Full Copyright Statement Copyright (C) The Internet Standards Process," RFC 2026, Harvard University, October 1996. [RFC-2119] Bradner, S., "Key wordsSociety (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for usethe purpose of developing Internet standards in RFCswhich case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to Indicate Requirement Levels," Harvard University, March 1997.translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This draftdocument and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. This Internet-Draft expires July 24, 2002June 5, 2003.