--- 1/draft-ietf-tsvwg-udp-guidelines-09.txt 2008-08-22 22:12:19.000000000 +0200 +++ 2/draft-ietf-tsvwg-udp-guidelines-10.txt 2008-08-22 22:12:19.000000000 +0200 @@ -1,19 +1,19 @@ Transport Area Working Group L. Eggert Internet-Draft Nokia Intended status: BCP G. Fairhurst -Expires: January 9, 2009 University of Aberdeen - July 8, 2008 +Expires: February 23, 2009 University of Aberdeen + August 22, 2008 - Guidelines for Application Designers on Using Unicast UDP - draft-ietf-tsvwg-udp-guidelines-09 + Unicast UDP Usage Guidelines for Application Designers + draft-ietf-tsvwg-udp-guidelines-10 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,21 +24,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 9, 2009. + This Internet-Draft will expire on February 23, 2009. Abstract The User Datagram Protocol (UDP) provides a minimal, message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of @@ -54,21 +54,21 @@ 3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 5 3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 6 3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 11 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 12 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 13 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 15 3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 17 3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27 1. Introduction The User Datagram Protocol (UDP) [RFC0768] provides a minimal, @@ -271,35 +271,35 @@ [RFC3448], window-based, TCP-like congestion control, or otherwise ensure that the application complies with the congestion control principles. TFRC has been designed to provide both congestion control and fairness in a way that is compatible with the IETF's other transport protocols. TFRC is currently being updated [I-D.ietf-dccp-rfc3448bis], and application designers SHOULD always evaluate whether the latest published specification fits their needs. If an application implements TFRC, it need not follow the remaining - guidelines in Section 3.1, because TFRC already addresses them, but + guidelines in Section 3.1.1, because TFRC already addresses them, but SHOULD still follow the remaining guidelines in the subsequent subsections of Section 3. Bulk transfer applications that choose not to implement TFRC or TCP- like windowing SHOULD implement a congestion control scheme that results in bandwidth use that competes fairly with TCP within an - order of magnitude. [RFC3551] suggests that applications SHOULD - monitor the packet loss rate to ensure that it is within acceptable - parameters. Packet loss is considered acceptable if a TCP flow - across the same network path under the same network conditions would - achieve an average throughput, measured on a reasonable timescale, - that is not less than that of the UDP flow. The comparison to TCP - cannot be specified exactly, but is intended as an "order-of- - magnitude" comparison in timescale and throughput. + order of magnitude. Section 2 of [RFC3551] suggests that + applications SHOULD monitor the packet loss rate to ensure that it is + within acceptable parameters. Packet loss is considered acceptable + if a TCP flow across the same network path under the same network + conditions would achieve an average throughput, measured on a + reasonable timescale, that is not less than that of the UDP flow. + The comparison to TCP cannot be specified exactly, but is intended as + an "order-of-magnitude" comparison in timescale and throughput. Finally, some bulk transfer applications may choose not to implement any congestion control mechanism and instead rely on transmitting across reserved path capacity. This might be an acceptable choice for a subset of restricted networking environments, but is by no means a safe practice for operation in the Internet. When the UDP traffic of such applications leaks out on unprovisioned Internet paths, it can significantly degrade the performance of other traffic sharing the path and even result in congestion collapse. Applications that support an uncontrolled or unadaptive transmission @@ -408,21 +408,21 @@ However, if the IP traffic in the tunnel is known to not be congestion-controlled, additional measures are RECOMMENDED in order to limit the impact of the tunneled traffic on other traffic sharing the path. The following guidelines define these possible cases in more detail: 1. A tunnel generates UDP traffic at a volume that corresponds to the volume of payload traffic, and the payload traffic is IP- - based and hence assumed to be congestion-controlled. + based and congestion-controlled. This is arguably the most common case for Internet tunnels. In this case, the UDP tunnel SHOULD NOT employ its own congestion control mechanism, because congestion losses of tunneled traffic will already trigger an appropriate congestion response at the original senders of the tunneled traffic. Note that this guideline is built on the assumption that most IP- based communication is congestion-controlled. If a UDP tunnel is used for IP-based traffic that is known to not be congestion- @@ -555,21 +555,21 @@ An application that requires reliable and ordered message delivery SHOULD choose an IETF standard transport protocol that provides these features. If this is not possible, it will need to implement a set of appropriate mechanisms itself. 3.4. Checksum Guidelines The UDP header includes an optional, 16-bit ones-complement checksum that provides an integrity check. This results in a relatively weak - protection from a coding point of view [RFC3819] and application + protection from in terms of coding theory [RFC3819] and application developers SHOULD implement additional checks where data integrity is important, e.g., through a Cyclic Redundancy Check (CRC) included with the data to verify the integrity of an entire object/file sent over UDP service. The UDP checksum provides a statistical guarantee that the payload was not corrupted in transit. It also allows the receiver to verify that it was the intended destination of the packet, because it covers the IP addresses, port numbers and protocol number, and it verifies that the packet is not truncated or padded, because it covers the @@ -692,30 +692,30 @@ An application that needs to employ keep-alives to deliver useful service over UDP in the presence of middleboxes SHOULD NOT transmit them more frequently than once every 15 seconds and SHOULD use longer intervals when possible. No common timeout has been specified for per-flow UDP state for arbitrary middleboxes. For NATs, [RFC4787] requires a state timeout of 2 minutes or longer. However, empirical evidence suggests that a significant fraction of the deployed middleboxes unfortunately uses shorter timeouts. The timeout of 15 seconds originates with the Interactive Connectivity Establishment - (ICE) protocol [I-D.ietf-mmusic-ice]. Applications that operate in - more controlled network environments SHOULD investigate whether the - environment they operate in allows them to use longer intervals, or - whether it offers mechanisms to explicitly control middlebox state - timeout durations, for example, using MIDCOM [RFC3303], NSIS - [I-D.ietf-nsis-nslp-natfw] or UPnP [UPNP]. It is RECOMMENDED that - applications apply slight random variations ("jitter") to the timing - of keep-alive transmissions, in order to reduce the potential for - persistent synchronization between keep-alive transmissions from - different hosts. + (ICE) protocol [I-D.ietf-mmusic-ice]. When applications are deployed + in more controlled network environments, the deployers SHOULD + investigate whether the target environment allows applications to use + longer intervals, or whether it offers mechanisms to explicitly + control middlebox state timeout durations, for example, using MIDCOM + [RFC3303], NSIS [I-D.ietf-nsis-nslp-natfw] or UPnP [UPNP]. It is + RECOMMENDED that applications apply slight random variations + ("jitter") to the timing of keep-alive transmissions, in order to + reduce the potential for persistent synchronization between keep- + alive transmissions from different hosts. Sending keep-alives is not a substitute for implementing robust connection handling. Like all UDP datagrams, keep-alives can be delayed or dropped, causing middlebox state to time out. In addition, the congestion control guidelines in Section 3.1 cover all UDP transmissions by an application, including the transmission of middlebox keep-alives. Congestion control may thus lead to delays or temporary suspension of keep-alive transmission. Keep-alive messages are NOT RECOMMENDED for general use. They are @@ -751,26 +751,26 @@ connection setup. Using the sockets API, applications can receive packets from more than one IP source address on a single UDP socket. Some servers use this to exchange data with more than one remote host through a single UDP socket at the same time. When applications need to ensure that they receive packets from a particular source address, they MUST implement corresponding checks at the application layer or explicitly request that the operating system filter the received packets. If a client/server application executes on a host with more than one - IP interface, the application SHOULD send any UDP responses in reply - to arriving UDP datagrams with an IP source address that matches the - IP destination address of the datagram that carried the request (see - [RFC1122], Section 4.1.3.5). Many middleboxes expect this - transmission behavior and drop replies that are sent from a different - IP address, as explained in Section 3.5. + IP interface, the application SHOULD send any UDP responses with an + IP source address that matches the IP destination address of the UDP + datagram that carried the request (see [RFC1122], Section 4.1.3.5). + Many middleboxes expect this transmission behavior and drop replies + that are sent from a different IP address, as explained in + Section 3.5. A UDP receiver can receive a valid UDP datagram with a zero-length payload. Note that this is different from a return value of zero from a read() socket call, which for TCP indicates the end of the connection. Many operating systems also allow a UDP socket to be connected, i.e., to bind a UDP socket to a specific pair of addresses and ports. This is similar to the corresponding TCP sockets API functionality. However, for UDP, this is only a local operation that serves to @@ -825,21 +825,25 @@ context, such as local state about communication instances to each destination, that although readily available in connection-oriented transport protocols is not always maintained by UDP-based applications. 4. Security Considerations UDP does not provide communications security. Applications that need to protect their communications against eavesdropping, tampering, or message forgery SHOULD employ end-to-end security services provided - by other IETF protocols. + by other IETF protocols. Applications that respond to short requests + with potentially large responses are vulnerable to amplification + attacks, and SHOULD authenticate the sender before responding. The + source IP address of a request is not a useful authenticator, because + it can be spoofed. One option of securing UDP communications is with IPsec [RFC4301], which can provide authentication for flows of IP packets through the Authentication Header (AH) [RFC4302] and encryption and/or authentication through the Encapsulating Security Payload (ESP) [RFC4303]. Applications use the Internet Key Exchange (IKE) [RFC4306] to configure IPsec for their sessions. Depending on how IPsec is configured for a flow, it can authenticate or encrypt the UDP headers as well as UDP payloads. If an application only requires authentication, ESP with no encryption but with authentication is @@ -1023,22 +1027,22 @@ draft-ietf-mmusic-ice-19 (work in progress), October 2007. [I-D.ietf-nsis-nslp-natfw] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-18 (work in progress), February 2008. [I-D.ietf-nsis-ntlp] Schulzrinne, H. and R. Hancock, "GIST: General Internet - Signalling Transport", draft-ietf-nsis-ntlp-15 (work in - progress), February 2008. + Signalling Transport", draft-ietf-nsis-ntlp-16 (work in + progress), July 2008. [POSIX] IEEE Std. 1003.1-2001, "Standard for Information Technology - Portable Operating System Interface (POSIX)", Open Group Technical Standard: Base Specifications Issue 6, ISO/IEC 9945:2002, December 2001. [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984. [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5,