idnits 2.17.1 draft-ietf-tsvwg-udp-lite-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC-768]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 5, 2002) is 7813 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC-2026' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'RFC-2402' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'RFC-2406' is defined on line 378, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 1071 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 1889 (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L-A. Larzon 3 INTERNET-DRAFT Lulea University of Technology 4 Expires: June 2003 M. Degermark 5 S. Pink 6 The University of Arizona 7 L-E. Jonsson (editor) 8 Ericsson 9 G. Fairhurst (editor) 10 University of Aberdeen 11 December 5, 2002 13 The UDP-Lite Protocol 14 16 Status of this memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/lid-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Please direct comments to the TSV WG mailing list: tsvwg@ietf.org 38 Abstract 40 This document describes the UDP-Lite protocol, which is similar to 41 UDP [RFC-768], but can also serve applications that in error-prone 42 network environments prefer to have partially damaged payloads 43 delivered rather than discarded. If this feature is not used, UDP- 44 Lite is semantically identical to UDP. 46 Table of Contents 48 1. Introduction...................................................2 49 2. Terminology....................................................3 50 3. Protocol Description...........................................3 51 3.1. Fields....................................................3 52 3.2. Pseudo Header.............................................4 53 3.3. Application Interface.....................................4 54 3.4. IP Interface..............................................5 55 3.5. Jumbograms................................................5 56 4. Lower Layer Considerations.....................................5 57 5. Compatibility with UDP.........................................6 58 6. Security Considerations........................................7 59 7. IANA Considerations............................................7 60 8. References.....................................................8 61 8.1. Normative References......................................8 62 8.2. Informative References....................................8 63 9. Acknowledgements...............................................8 64 10. Authors' Addresses............................................9 66 1. Introduction 68 Why another transport protocol? 70 First, there is a class of applications that prefer to have damaged 71 data delivered rather than discarded by the network. A number of 72 codecs for voice and video fall into this class. These codecs are 73 designed to cope better with errors in the payload than with loss of 74 entire packets. 76 Second, there are a number of link technologies where data can be 77 partially damaged. Several radio technologies exhibit this behavior 78 when operating at a point where cost and delay are sufficiently low. 80 Third, intermediate layers should not prevent error-tolerant 81 applications to run well in the presence of such links. The 82 intermediate layers are IP and the transport layer. IP is not a 83 problem in this regard since the IP header has no checksum that 84 covers the IP payload. The generally available transport protocol 85 best suited for these applications is UDP, since it has no overhead 86 for retransmission of erroneous packets, in-order delivery, or error 87 correction. In IPv4 [RFC-791], the UDP checksum covers either the 88 entire packet or nothing at all. In IPv6 [RFC-2460], the UDP checksum 89 is mandatory and must not be disabled. The IPv6 header does not have 90 a header checksum and it was deemed necessary to always protect the 91 IP addressing information by making the UDP checksum mandatory. 93 A transport protocol is needed that conforms to the properties of 94 link layers and applications described above [UDP-LITE]. The error- 95 detection mechanism of the transport layer must be able to protect 96 vital information such as headers, but also to optionally ignore 97 errors best dealt with by the application. What should be verified by 98 the checksum is best specified by the sending application. 100 UDP-Lite provides a checksum with an optional partial coverage. When 101 using this option, a packet is divided into a sensitive part (covered 102 by the checksum) and an insensitive part (not covered by the 103 checksum). Errors in the insensitive part will not cause the packet 104 to be discarded by the transport layer at the receiving end host. 105 When the checksum covers the entire packet, which should be the 106 default, UDP-Lite is semantically identical to UDP. 108 Compared to UDP, the UDP-Lite partial checksum provides extra 109 flexibility for applications that want to define the payload as 110 partially insensitive to bit errors. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC-2119]. 118 3. Protocol Description 120 The UDP-Lite header is shown in figure 1. Its format differs from 121 UDP in that the Length field has been replaced with a Checksum 122 Coverage field. This can be done since information about UDP packet 123 length can be provided by the IP module in the same manner as for TCP 124 [RFC-793]. 126 0 15 16 31 127 +--------+--------+--------+--------+ 128 | Source | Destination | 129 | Port | Port | 130 +--------+--------+--------+--------+ 131 | Checksum | | 132 | Coverage | Checksum | 133 +--------+--------+--------+--------+ 134 | | 135 : Payload : 136 | | 137 +-----------------------------------+ 139 Figure 1: UDP-Lite Header Format 141 3.1. Fields 143 The fields Source Port and Destination Port are defined as in the UDP 144 specification [RFC-768]. UDP-Lite uses the same set of port number 145 values as those assigned by the IANA for use by UDP. 147 Checksum Coverage is the number of octets, counting from the first 148 octet of the UDP-Lite header, that are covered by the checksum. The 149 UDP-Lite header MUST always be covered by the checksum. Despite this 150 requirement, the Checksum Coverage is expressed in octets from the 151 beginning of the UDP-Lite header, in the same way as for UDP. A 152 Checksum Coverage of zero indicates that the entire UDP-Lite packet 153 is covered by the checksum. This means that the value of the Checksum 154 Coverage field MUST be either 0 or at least 8. A UDP-Lite packet with 155 a Checksum Coverage value of 1 to 7 MUST be discarded by the 156 receiver. UDP-Lite packets with a Checksum Coverage greater than the 157 IP length MUST also be discarded. 159 Checksum is the 16-bit one's complement of the one's complement sum 160 of a pseudo-header of information from the IP header, the number of 161 octets specified by the Checksum Coverage (starting at the first 162 octet in the UDP-Lite header), virtually padded with a zero octet at 163 the end (if necessary) to make a multiple of two octets [RFC-1071]. 164 If the computed checksum is 0, it is transmitted as all ones (the 165 equivalent in one's complement arithmetic). 167 The transmitted checksum MUST NOT be all zeroes. If an application 168 using UDP-Lite wishes to have no protection of the packet payload, it 169 should use a Checksum Coverage value of 8. This differs from the use 170 of UDP over IPv4, in that the minimal UDP-Lite checksum always covers 171 the UDP-Lite protocol header, which includes the Checksum Coverage 172 field. 174 3.2. Pseudo Header 176 UDP and UDP-Lite use the same conceptually prefixed pseudo header 177 from the IP layer for the checksum. This pseudo header is different 178 for IPv4 and IPv6. The pseudo header of UDP-Lite is different from 179 the pseudo header of UDP in one way: The value of the Length field of 180 the pseudo header is not taken from the UDP-Lite header, but rather 181 from information provided by the IP module. This computation is done 182 in the same manner as for TCP [RFC-793], and implies that the Length 183 field of the pseudo header includes the UDP-Lite header and all 184 subsequent octets in the IP payload. 186 3.3. Application Interface 188 An application interface should allow the same operations as for 189 UDP. In addition to this, it should provide a way for the sending 190 application to pass the checksum coverage value to the UDP-Lite 191 module. There should also be a way to pass the checksum coverage 192 value to the receiving application, or at least let the receiving 193 application block delivery of packets with coverage values less than 194 a value provided by the application. 196 It is RECOMMENDED that the default behavior of UDP-Lite be to mimic 197 UDP by having the Checksum Coverage field match the length of the 198 UDP-Lite packet, and verify the entire packet. Applications that want 199 to define the payload as partially insensitive to bit errors (e.g. 200 error tolerant codecs using RTP [RFC-1889]) should do that by an 201 explicit system call on the sender side. Applications that wish to 202 receive payloads that were only partially covered by a checksum 203 should inform the receiving system by an explicit system call. 205 The characteristics of the links forming an Internet path may vary 206 greatly. It is therefore difficult to make assumptions about the 207 level or patterns of errors that may occur in the insensitive part of 208 the UDP-Lite payload. Applications that use UDP-Lite should not make 209 any assumptions regarding the correctness of the received data beyond 210 the indicated checksum coverage, and should if necessary introduce 211 their own appropriate validity checks. 213 3.4. IP Interface 215 As for UDP, the IP module must provide the pseudo header to the UDP- 216 Lite module. The UDP-Lite pseudo header contains the IP addresses and 217 protocol fields of the IP header, and also the length of the IP 218 payload, which is derived from the Length field of the IP header. 220 The sender IP module MUST NOT pad the IP payload with extra octets 221 since the length of the UDP-Lite payload delivered to the receiver 222 depends on the length of the IP payload. 224 3.5. Jumbograms 226 The Checksum Coverage field is 16 bits and can represent a checksum 227 coverage of up to 65535 octets. This allows arbitrary checksum 228 coverage for IP packets, unless they are Jumbograms. For Jumbograms, 229 the checksum can cover either the entire payload (when the Checksum 230 Coverage field has the value zero), or else at most the initial 65535 231 octets of the UDP-Lite packet. 233 4. Lower Layer Considerations 235 Since UDP-Lite can deliver packets with damaged payloads to an 236 application that wants them, frames carrying UDP-Lite packets need 237 not be discarded by lower layers when there are errors only in the 238 insensitive part. For a link that supports partial error detection, 239 the Checksum Coverage field in the UDP-Lite header MAY be used as a 240 hint of where errors do not need to be detected. Lower layers MUST 241 use a strong error detection mechanism to detect at least errors that 242 occur in the sensitive part of the packet, and discard damaged 243 packets. The sensitive part consists of the octets between the first 244 octet of the IP header and the last octet identified by the Checksum 245 Coverage field. At least the sensitive part would thus be treated in 246 exactly the same way as UDP packets. 248 Link layers that do not support partial error detection suitable for 249 UDP-Lite, as described above, MUST detect errors in the entire UDP- 250 Lite packet, and discard damaged packets. The whole UDP-Lite packet 251 is thus treated in exactly the same way as a UDP packet. 253 It should be noted that UDP-Lite would only make a difference to the 254 application if partial error detection, based on the partial checksum 255 feature of UDP-Lite, is implemented also by link layers, as discussed 256 above. Obviously, partial error detection at the link layer would 257 only make a difference when implemented over error-prone links. 259 5. Compatibility with UDP 261 UDP and UDP-Lite have similar syntax and semantics. Applications 262 designed for UDP may therefore use UDP-Lite instead, and will by 263 default receive the same full packet coverage. The similarities also 264 ease implementation of UDP-Lite, since only minor modifications are 265 needed to an existing UDP implementation. 267 UDP-Lite has been allocated a separate IP protocol identifier, XXXX 268 [INSERT IANA NUMBER BEFORE PUBLICATION], that allows a receiver to 269 identify whether UDP or UDP-Lite is used. A system unaware of UDP- 270 Lite will in general return an ICMP Protocol Unreachable error 271 message to the sender. This simple method of detecting UDP-Lite 272 unaware systems is the primary benefit of having separate protocol 273 identifiers. 275 The remainder of this section provides the rationale for allocating a 276 separate IP protocol identifier for UDP-Lite, rather than sharing the 277 IP protocol identifier with UDP. 279 There are no known interoperability problems between UDP and UDP-Lite 280 if they were to share the protocol identifier with UDP. Specifically, 281 there is no case where a potentially problematic packet is delivered 282 to an unsuspecting application; a UDP-Lite payload with partial 283 checksum coverage cannot be delivered to UDP applications, and UDP 284 packets that only partially fill the IP payload cannot be delivered 285 to applications using UDP-Lite. 287 However, if the protocol identifier were to be shared between UDP and 288 UDP-Lite, and a UDP-Lite implementation was to send a UDP-Lite packet 289 using a partial checksum to a UDP implementation, the UDP 290 implementation would silently discard the packet, because a 291 mismatching pseudo header would cause the UDP checksum to fail. 292 Neither the sending nor the receiving application would be notified. 293 Potential solutions to this could have been: 295 1) explicit application in-band signaling (while not using the 296 partial checksum coverage option) to enable the sender to learn 297 whether the receiver is UDP-Lite enabled or not, or 299 2) use of out-of-band signaling such as H.323, SIP, or RTCP to 300 convey whether the receiver is UDP-Lite enabled. 302 Anyway, since UDP-Lite has now been assigned its own protocol 303 identifier, there is no need to consider the possibility of delivery 304 of a UDP-Lite packet to an unsuspecting UDP port. 306 6. Security Considerations 308 The security impact of UDP-Lite is related to its interaction with 309 authentication and encryption mechanisms. When the partial checksum 310 option of UDP-Lite is enabled, the insensitive portion of a packet 311 may change in transit. This is contrary to the idea behind most 312 authentication mechanisms: authentication succeeds if the packet has 313 not changed in transit. Unless authentication mechanisms that operate 314 only on the sensitive part of packets are developed and used, 315 authentication will always fail on UDP-Lite packets where the 316 insensitive part has been damaged. 318 The IPSec integrity check (Encapsulation Security Protocol, ESP, or 319 Authentication Header, AH) is applied (at least) to the entire IP 320 packet payload. Corruption of any bit within the protected area will 321 then result in the discarding of the UDP-Lite packet by the IP 322 receiver. 324 Encryption is also an issue when using UDP-Lite. If a few bits of an 325 encrypted packet are damaged, the decryption transform will typically 326 spread errors so that the packet becomes too damaged to be of use. 327 Many strong encryption transforms today exhibit this behavior, for 328 reasons obvious from a security point of view. There exist encryption 329 transforms, stream ciphers, which do not spread errors in this way 330 when the damage occurs in the insensitive part of the packet. 332 7. IANA Considerations 334 A new IP protocol number, XXXX [INSERT NUMBER BEFORE PUBLICATION], 335 has been assigned for UDP-Lite. 337 [NOTE, REMOVE BEFORE PUBLICATION] 339 IANA assignment instruction: 340 - The IANA must reserve an IP protocol number for UDP-Lite. 342 [END OF NOTE] 344 8. References 346 8.1. Normative References 348 [RFC-768] Postel, J., "User Datagram Protocol", RFC 768 (STD6), 349 August 1980. 351 [RFC-791] Postel, J., "Internet Protocol", RFC 791 (STD5), 352 September 1981. 354 [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793 355 (STD7), September 1981. 357 [RFC-1071] Braden, R., Borman, D., and C. Partridge, "Computing the 358 Internet Checksum", RFC 1071, September 1988. 360 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", RFC 2119 (BCP15), March 1997. 363 [RFC-2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6 364 (IPv6) Specification", RFC 2460, December 1998. 366 8.2. Informative References 368 [RFC-1889] Schulzrinne, H., Casner, S., Frederick, R., and 369 V. Jacobson, "RTP: A Transport Protocol for Real-Time 370 Applications", RFC 1889, January 1996. 372 [RFC-2026] Bradner, S., "The Internet Standards Process", RFC 2026, 373 October 1996. 375 [RFC-2402] Kent, S., and R. Atkinson, "IP Authentication Header", 376 RFC 2402, November 1998. 378 [RFC-2406] Kent, S., and R. Atkinson, "IP Encapsulating Security 379 Payload (ESP)", RFC 206, November 1998. 381 [UDP-LITE] Larzon, L-A., Degermark, M., and S. Pink, "UDP Lite for 382 Real-Time Multimedia Applications", Proceedings of the 383 IEEE International Conference of Communications (ICC), 384 1999. 386 9. Acknowledgements 388 Thanks to Ghyslain Pelletier for significant technical and editorial 389 comments. Thanks also to Elisabetta Carrara and Mats Naslund for 390 reviewing the security considerations chapter, and to Peter Eriksson 391 for doing a language review and thereby improving the clarity of this 392 document. 394 10. Authors' Addresses 396 Lars-Ake Larzon 397 Department of CS & EE 398 Lulea University of Technology 399 S-971 87 Lulea, Sweden 400 Email: lln@cdt.luth.se 402 Mikael Degermark 403 Department of Computer Science 404 The University of Arizona 405 P.O. Box 210077 406 Tucson, AZ 85721-0077, USA 407 Email: micke@cs.arizona.edu 409 Stephen Pink 410 The University of Arizona 411 P.O. Box 210077 412 Tucson, AZ 85721-0077, USA 413 Email: steve@cs.arizona.edu 415 Lars-Erik Jonsson 416 Ericsson AB 417 Box 920 418 S-971 28 Lulea, Sweden 419 Email: lars-erik.jonsson@ericsson.com 421 Godred Fairhurst 422 Department of Engineering 423 University of Aberdeen 424 Aberdeen, AB24 3UE, UK 425 Email: gorry@erg.abdn.ac.uk 427 Full Copyright Statement 429 Copyright (C) The Internet Society (2002). All Rights Reserved. 431 This document and translations of it may be copied and furnished to 432 others, and derivative works that comment on or otherwise explain it 433 or assist in its implementation may be prepared, copied, published 434 and distributed, in whole or in part, without restriction of any 435 kind, provided that the above copyright notice and this paragraph are 436 included on all such copies and derivative works. However, this 437 document itself may not be modified in any way, such as by removing 438 the copyright notice or references to the Internet Society or other 439 Internet organizations, except as needed for the purpose of 440 developing Internet standards in which case the procedures for 441 copyrights defined in the Internet Standards process must be 442 followed, or as required to translate it into languages other than 443 English. 445 The limited permissions granted above are perpetual and will not be 446 revoked by the Internet Society or its successors or assigns. 448 This document and the information contained herein is provided on an 449 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 450 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 451 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 452 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 453 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 455 This Internet-Draft expires June 5, 2003.