--- 1/draft-ietf-tsvwg-udp-guidelines-05.txt 2008-04-03 19:12:16.000000000 +0200 +++ 2/draft-ietf-tsvwg-udp-guidelines-06.txt 2008-04-03 19:12:16.000000000 +0200 @@ -1,19 +1,19 @@ Transport Area Working Group L. Eggert Internet-Draft Nokia -Intended status: Best Current G. Fairhurst -Practice University of Aberdeen -Expires: August 8, 2008 February 5, 2008 +Intended status: BCP G. Fairhurst +Expires: October 5, 2008 University of Aberdeen + April 3, 2008 UDP Usage Guidelines for Application Designers - draft-ietf-tsvwg-udp-guidelines-05 + draft-ietf-tsvwg-udp-guidelines-06 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,25 +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 August 8, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2008). + This Internet-Draft will expire on October 5, 2008. 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 @@ -55,21 +51,21 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 4 3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 5 3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 10 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 11 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 12 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 13 3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 15 - 3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 17 + 3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 26 @@ -279,24 +275,24 @@ 3.1.2. Low Data-Volume Applications When applications that exchange only a small number of messages with a destination at any time implement TFRC or one of the other congestion control schemes in Section 3.1.1, the network sees little benefit, because those mechanisms perform congestion control in a way that is only effective for longer transmissions. Applications that exchange only a small number of messages with a destination at any time SHOULD still control their transmission - behavior by not sending more than one UDP message per round-trip time - (RTT) to a destination. Similar to the recommendation in [RFC1536], - an application SHOULD maintain an estimate of the RTT for any - destination with which it communicates. Applications SHOULD + behavior by not sending on average more than one UDP message per + round-trip time(RTT) to a destination. Similar to the recommendation + in [RFC1536], an application SHOULD maintain an estimate of the RTT + for any destination with which it communicates. Applications SHOULD implement the algorithm specified in [RFC2988] to compute a smoothed RTT (SRTT) estimate. They SHOULD also detect packet loss and exponentially back-off their retransmission timer when a loss event occurs. When implementing this scheme, applications need to choose a sensible initial value for the RTT. This value SHOULD generally be as conservative as possible for the given application. TCP uses an initial value of 3 seconds [RFC2988], which is also RECOMMENDED as an initial value for UDP applications. SIP [RFC3261] and GIST [I-D.ietf-nsis-ntlp] use an initial value of 500 ms, and initial timeouts that are shorter than this are likely problematic in many @@ -418,21 +414,21 @@ Examples of this class include UDP tunnels that send at a constant rate, increase their transmission rates under loss, for example, due to increasing redundancy when forward-error- correction is used, or are otherwise constrained in their transmission behavior. These specialized uses of UDP for tunneling go beyond the scope of the general guidelines given in this document. The implementer of such specialized tunnels SHOULD carefully consider congestion control in the design of their tunneling mechanism. - Designing tunneling mechanism requires significantly more expertise + Designing a tunneling mechanism requires significantly more expertise than needed for many other UDP applications, because tunnels virtualize lower-layer components of the Internet, and the virtualized components need to correctly interact with the infrastructure at that layer. This document only touches upon the congestion control considerations for implementing UDP tunnels; a discussion of other required tunneling behavior is out of scope. 3.2. Message Size Guidelines IP fragmentation lowers the efficiency and reliability of Internet @@ -470,23 +466,23 @@ larger PMTU, which is a second reason to implement PMTU discovery. To determine an appropriate UDP payload size, applications MUST subtract the size of the IP header (which includes any IPv4 optional headers or IPv6 extension headers) as well as the length of the UDP header (8 bytes) from the PMTU size. This size, known as the MMS_S, can be obtained from the TCP/IP stack [RFC1122]. Applications that do not send messages that exceed the effective PMTU of IPv4 or IPv6 need not implement any of the above mechanisms. Note - that the presence of tunnels can cause fragmentation even when - applications send messages that do not exceed the effective PMTU, so - implementing PMTU discovery will still be beneficial in some cases. + that the presence of tunnels can cause an additional reduction of the + effective PMTU, so implementing PMTU discovery will still be + beneficial in some cases. 3.3. Reliability Guidelines Application designers are generally aware that UDP does not provide any reliability, e.g., it does not retransmit any lost packets. Often, this is a main reason to consider UDP as a transport. Applications that do require reliable message delivery MUST implement an appropriate mechanism themselves. UDP also does not protect against message duplication, i.e., an @@ -584,21 +580,21 @@ The receiver MUST set a minimum coverage threshold for incoming packets that is not smaller than the smallest coverage used by the sender. This may be a fixed value, or may be negotiated by an application. UDP-Lite does not provide mechanisms to negotiate the checksum coverage between the sender and receiver. Applications may still experience packet loss, rather than corruption, when using UDP-Lite. The enhancements offered by UDP- Lite rely upon a link being able to intercept the UDP-Lite header to - correctly identify the partial-coverage required. When tunnels + correctly identify the partial coverage required. When tunnels and/or encryption are used, this can result in UDP-Lite messages being treated the same as UDP messages, i.e., result in packet loss. Use of IP fragmentation can also prevent special treatment for UDP- Lite messages, and is another reason why applications SHOULD avoid IP fragmentation Section 3.2. 3.5. Middlebox Traversal Guidelines Network address translators (NATs) and firewalls are examples of intermediary devices ("middleboxes") that can exist along an end-to- @@ -652,22 +648,21 @@ 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], STUN - [I-D.wing-behave-nat-control-stun-usage] or UPnP [UPNP]. + [I-D.ietf-nsis-nslp-natfw] or UPnP [UPNP]. It is important to note that sending keep-alives is not a substitute for implementing robust connection handling. Like all UDP messages, 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. @@ -708,47 +703,46 @@ 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 simplify the local send/receive functions and to filter the traffic for the specified addresses and ports. Binding a UDP socket does not establish a connection - UDP does not notify the remote end when a local UDP socket is bound. Binding a socket also allows configuring options that affect the UDP or IP layers, for example, use of the UDP - checksum or IP source routing. On some stacks, a bound socket also - allows an application to be notified when ICMP error messages are - received for its transmissions [RFC1122]. + checksum or the IP Time Stamp Option. On some stacks, a bound socket + also allows an application to be notified when ICMP error messages + are received for its transmissions [RFC1122]. UDP provides no flow-control. This is another reason why UDP-based applications need to be robust in the presence of packet loss. This loss can also occur within the sending host, when an application sends data faster than the line rate of the outbound network interface. It can also occur on the destination, where receive calls - fail to return data when the application issues them too frequently - (i.e., when no new data has arrived) or not frequently enough (i.e., - such that the receive buffer overflows). Robust flow control - mechanisms are difficult to implement, which is why applications that - need this functionality SHOULD consider using a full-featured - transport protocol. + fail to return all the data that was sent when the application issues + them too infrequently (i.e., such that the receive buffer overflows). + Robust flow control mechanisms are difficult to implement, which is + why applications that need this functionality SHOULD consider using a + full-featured transport protocol. When an application closes a TCP, SCTP or DCCP socket, the transport protocol on the receiving host is required to maintain TIME-WAIT state. This prevents delayed packets from the closed connection instance from being mistakenly associated with a later connection instance that happens to reuse the same IP address and port pairs. The UDP protocol does not implement such a mechanism. Therefore, - UDP-based applications need to robust to this case. One application - may close a socket or terminate, followed in time by another - application receiving on the same port. This later application may - then receive packets intended for the first application that were - delayed in the network. + UDP-based applications need to be robust in this case. One + application may close a socket or terminate, followed in time by + another application receiving on the same port. This later + application may then receive packets intended for the first + application that were delayed in the network. 3.7. ICMP Guidelines Applications can utilize information about ICMP error messages that the UDP layer passes up for a variety of purposes [RFC1122]. Applications SHOULD validate that the information in the ICMP message payload, e.g., a reported error condition, corresponds to a UDP datagram that the application actually sent. Note that not all APIs have the necessary functions to support this validation, and some APIs already perform this validation internally before passing ICMP @@ -787,29 +781,30 @@ Although it is possible to use IPsec to secure UDP communications, not all operating systems support IPsec or allow applications to easily configure it for their flows. A second option of securing UDP communications is through Datagram Transport Layer Security (DTLS) [RFC4347]. DTLS provides communication privacy by encrypting UDP payloads. It does not protect the UDP headers. Applications can implement DTLS without relying on support from the operating system. Many other options for authenticating or encrypting UDP payloads - exist. These include IETF security frameworks such as GSS-API GSS- - API [RFC2743], SASL [RFC4422] and EAP [RFC3748], which are designed - to provide security services for network protocols. For some - applications, S/MIME [RFC3851] or PGP [RFC4880] might provide a - better solution, because they provide protection for larger - standalone objects such as files or messages. However, they - generally involve public-key operations on an entire object, which - can have performance implications. In addition, there are many non- - IETF protocols in this area. + exist. These include IETF security frameworks such as GSS-API + [RFC2743], SASL [RFC4422] and EAP [RFC3748], which are designed to + provide security services for network protocols. The IETF standard + for securing RTP [RFC3550] realtime communication sessions over UDP + is SRTP [RFC3711]. For some other applications, S/MIME [RFC3851] or + PGP [RFC4880] might provide a better solution, because they provide + protection for larger standalone objects such as files or messages. + However, they generally involve public-key operations on an entire + object, which can have performance implications. In addition, there + are many non-IETF protocols in this area. Like congestion control mechanisms, security mechanisms are difficult to design and implement correctly. It is hence RECOMMENDED that applications employ well-known standard security mechanisms such as DTLS or IPsec, rather than inventing their own. In terms of congestion control, [RFC2309] and [RFC2914] discuss the dangers of congestion-unresponsive flows to the Internet. This document provides guidelines to designers of UDP-based applications to congestion-control their transmissions, and does not raise any @@ -938,52 +933,46 @@ [I-D.ford-behave-app] Ford, B., "Application Design Guidelines for Traversal through Network Address Translators", draft-ford-behave-app-05 (work in progress), March 2007. [I-D.ietf-dccp-ccid4] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", - draft-ietf-dccp-ccid4-01 (work in progress), - November 2007. + draft-ietf-dccp-ccid4-02 (work in progress), + February 2008. [I-D.ietf-dccp-rfc3448bis] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", - draft-ietf-dccp-rfc3448bis-04 (work in progress), - January 2008. + draft-ietf-dccp-rfc3448bis-05 (work in progress), + February 2008. [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", 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-17 (work in progress), - January 2008. + 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. - [I-D.wing-behave-nat-control-stun-usage] - Wing, D., Rosenberg, J., and H. Tschofenig, "Discovering, - Querying, and Controlling Firewalls and NATs", - draft-wing-behave-nat-control-stun-usage-05 (work in - progress), October 2007. - [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984. [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, October 1993. [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, @@ -1019,20 +1009,24 @@ RFC 3493, February 2003. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, March 2004. + [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004. @@ -1155,15 +1149,10 @@ attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA).