--- 1/draft-ietf-6man-udpzero-02.txt 2011-04-21 11:16:11.000000000 +0200 +++ 2/draft-ietf-6man-udpzero-03.txt 2011-04-21 11:16:11.000000000 +0200 @@ -1,19 +1,19 @@ Internet Engineering Task Force G. Fairhurst Internet-Draft University of Aberdeen Intended status: Informational M. Westerlund -Expires: April 27, 2011 Ericsson - October 24, 2010 +Expires: October 23, 2011 Ericsson + April 21, 2011 IPv6 UDP Checksum Considerations - draft-ietf-6man-udpzero-02 + draft-ietf-6man-udpzero-03 Abstract This document examines the role of the UDP transport checksum when used with IPv6, as defined in RFC2460. It presents a summary of the trade-offs for evaluating the safety of updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value in the checksum field as an indication that no checksum is present. This method is compared with some other possibilities. The document also describes the issues and design principles that need to be considered when UDP is used with @@ -29,25 +29,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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 to cite them other than as "work in progress." - This Internet-Draft will expire on April 27, 2011. + This Internet-Draft will expire on October 23, 2011. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -99,31 +99,31 @@ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 Appendix A. Document Change History . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction - The User Datagram Protocol (UDP) transport was defined by RFC768 - [RFC0768] for IPv4 RFC791 [RFC0791] and is defined in RFC2460 - [RFC2460] for IPv6 hosts and routers. The UDP transport protocol has - a minimal set of features. This limited set has enabled a wide range - of applications to use UDP, but these application do need to provide - many important transport functions on top of UDP. The UDP Usage - Guidelines [RFC5405] provides overall guidance for application - designers, including the use of UDP to support tunneling. The key - difference between UDP usage with IPv4 and IPv6 is that IPv6 mandates - use of the UDP checksum, i.e. a non-zero value, due to the lack of an - IPv6 header checksum. + The User Datagram Protocol (UDP) [RFC0768] transport is defined for + the Internet Protocol (IPv4) [RFC0791] and is defined in Internet + Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The + UDP transport protocol has a minimal set of features. This limited + set has enabled a wide range of applications to use UDP, but these + application do need to provide many important transport functions on + top of UDP. The UDP Usage Guidelines [RFC5405] provides overall + guidance for application designers, including the use of UDP to + support tunneling. The key difference between UDP usage with IPv4 + and IPv6 is that IPv6 mandates use of the UDP checksum, i.e. a non- + zero value, due to the lack of an IPv6 header checksum. The lack of a possibility to use UDP with a zero-checksum in IPv6 has been observed as a real problem for certain classes of application, primarily tunnel applications. This class of application has been deployed with a zero checksum using IPv4. The design of IPv6 raises different issues when considering the safety of using a zero checksum for UDP with IPv6. These issues can significantly affect applications, both when an endpoint is the intended user and when an innocent bystander (received by a different endpoint to that intended). The document examines these issues and compares the @@ -324,27 +324,28 @@ 1.3.2. Reducing forwarding cost It is a common requirement to terminate a large number of tunnels on a single router/host. Processing per tunnel concerns both state (memory requirements) and per-packet processing costs. Automatic IP Multicast Without Explicit Tunnels, known as AMT [AMT] currently specifies UDP as the transport protocol for packets carrying tunneled IP multicast packets. The current specification for AMT requires that the UDP checksum in the outer packet header - should be 0 (see Section 6.6). It argues that the computation of an - additional checksum, when an inner packet is already adequately - protected, is an unwarranted burden on nodes implementing lightweight - tunneling protocols. The AMT protocol needs to replicate a multicast - packet to each gateway tunnel. In this case, the outer IP addresses - are different for each tunnel and therefore require a different - pseudo header to be built for each UDP replicated encapsulation. + should be 0 (see Section 6.6 of [AMT]). It argues that the + computation of an additional checksum, when an inner packet is + already adequately protected, is an unwarranted burden on nodes + implementing lightweight tunneling protocols. The AMT protocol needs + to replicate a multicast packet to each gateway tunnel. In this + case, the outer IP addresses are different for each tunnel and + therefore require a different pseudo header to be built for each UDP + replicated encapsulation. The argument concerning redundant processing costs is valid regarding the integrity of a tunneled packet. In some architectures (e.g. PC- based routers), other mechanisms may also significantly reduce checksum processing costs: There are implementations that have optimised checksum processing algorithms, including the use of checksum-offloading. This processing is readily available for IPv4 packets at high line rates. Such processing may be anticipated for IPv6 endpoints, allowing receivers to reject corrupted packets without further processing. However, there are certain classes of @@ -449,21 +450,22 @@ UDP-Lite provides a checksum with optional partial coverage. When using this option, a datagram is divided into a sensitive part (covered by the checksum) and an insensitive part (not covered by the checksum). When the checksum covers the entire packet, UDP-Lite is fully equivalent with UDP. Errors/corruption in the insensitive part will not cause the datagram to be discarded by the transport layer at the receiving endpoint. A minor side-effect of using UDP-Lite is that this was specified for damage-tolerant payloads, and some link- layers may employ different link encapsulations when forwarding UDP- Lite segments (e.g. radio access bearers). Most link-layers will - also cover the insensitive part by a strong layer 2 frame CRC. + cover the insensitive part with the same strong layer 2 frame CRC + that covers the sensitive part. 2.2.1. Using UDP-Lite as a Tunnel Encapsulation Tunnel encapsulations can use UDP-Lite (e.g. Control And Provisioning of Wireless Access Points, CAPWAP [RFC5415]), since UDP- Lite provides a transport-layer checksum, including an IP pseudo header checksum, in IPv6, without the need for a router/middelbox to traverse the entire packet payload. This provides most of the delivery verifications and still keep the complexity of the checksumming operation low. UDP-Lite may set the length of checksum @@ -619,21 +621,21 @@ o A stateless application will process the datagram outside of any context, a simple example is the ECHO server, which will respond with a datagram directed to the modified source address. This would create unwanted additional processing load, and generate traffic to the modified endpoint address. o Some datagram applications build state using the information from packet headers. A previously unused source address would result in receiver processing and the creation of unnecessary transport- layer state at the receiver. For example, Real Time Protocol - (RTP) [RFC3550] flows commonly employ a source independent + (RTP) [RFC3550] sessions commonly employ a source independent receiver port. State is created for each received flow. Reception of a datagram with a corrupted source address will therefore result in accumulation of unnecessary state in the RTP state machine, including collision detection and response (since the same synchronization source, SSRC, value will appear to arrive from multiple source IP addresses). In general, the effect of corrupting the source address will depend upon the protocol that processes the packet and its robustness to this error. For the case where the packet is received by a tunnel @@ -650,42 +652,44 @@ values are corrupted in transit. This can also happen with IPv4 in the zero checksum case, but not when UDP checksums are enabled or with UDP-Lite. If the ports carried in the transport header of an IPv6 packet were corrupted in transit, packets may be delivered to the wrong process (on the intended machine) and/or responses or errors sent to the wrong application process (on the intended machine). 3.1.4. Delivery to an unexpected port - If one combines the corruption effects there is a number of potential - outcomes when traffic arrives at an unexpected port. This section - discusses these possibilities and their outcomes for a packet that - does not use the UDP checksum validation: + If one combines the corruption effects, such as destination address + and ports, there is a number of potential outcomes when traffic + arrives at an unexpected port. This section discusses these + possibilities and their outcomes for a packet that does not use the + UDP checksum validation: o Delivery to a port that is not in use. The packet is discarded, but could generate an ICMPv6 message (e.g. port unreachable). o It could be delivered to a different node that implements the same application, where the packet may be accepted, generating side- effects or accumulated state. o It could be delivered to an application that does not implement the tunnel protocol, where the packet may be incorrectly parsed, and may be misinterpreted, generating side-effects or accumulated state. The probability of each outcome depends on the statistical - probability that the source address and the destination port of the - datagram (the source port is not always used in UDP) match those of - an existing connection. Unfortunately, such a match may be more - likely for UDP than for connection-oriented transports, because: + probability that the address or the port information for the source + or destination becomes corrupt in the datagram such that they match + those of an existing flow or server port. Unfortunately, such a + match may be more likely for UDP than for connection-oriented + transports, because: 1. There is no handshake prior to communication and no sequence numbers (as in TCP, DCCP, or SCTP). Together, this makes it hard to verify that an application is given only the data associated with a transport session. 2. Applications writers often bind to wild-card values in endpoint identifiers and do not always validate correctness of datagrams they receive (guidance on this topic is provided in [RFC5405]). @@ -697,21 +701,21 @@ If checksum coverage is suppressed, the application therefore needs to provide a method to detect and discard the unwanted data. A tunnel protocol would need to perform its own integrity checks on any control information if transported in UDP with zero-checksum. If the tunnel payload is another IP packet, the packets requiring checksums can be assumed to have their own checksums provided that the rate of corrupted packets is not significantly larger due to the tunnel encapsulation. If a tunnel transports other inner payloads that do not use IP, the assumptions of corruption detection for that particular protocol must be fulfilled, this may require an additional - checksum/CRC and/or integrity protection > of the payload and tunnel + checksum/CRC and/or integrity protection of the payload and tunnel headers. A protocol using UDP zero-checksum can never assume that it is the only protocol using a zero checksum. Therefore, it needs to gracefully handle misdelivery. It must be robust to reception of malformed packets received on a listening port and expect that these packets may contain corrupted data or data associated with a completely different protocol. 3.1.5. Corruption of Fragmentation Information @@ -838,27 +842,28 @@ be expected to take time for deployment of any updated behaviour to become ubiquitous. A sender will need to probe the path to verify the expected behavior. Path characteristics may change, and usage therefore should be robust and able to detect a failure of the path under normal usage and re-negotiate. This will require periodic validation of the path, adding complexity to any solution using the new behavior. 3.3. Applicability of method - The expectation of the present proposal defined in [UDPZ] is that - this change would only apply to IPv6 router nodes that implement - specific protocols that permit omission of UDP checksums. However, - the distinction between a router and a host is not always clear, - especially at the transport level. Systems (such as unix-based - operating systems) routinely provide both functions. There is also - no way to identify the role of a receiver from a received packet. + The expectation of the present proposal defined in + [I-D.ietf-6man-udpchecksums] is that this change would only apply to + IPv6 router nodes that implement specific protocols that permit + omission of UDP checksums. However, the distinction between a router + and a host is not always clear, especially at the transport level. + Systems (such as unix-based operating systems) routinely provide both + functions. There is also no way to identify the role of a receiver + from a received packet. Any new method would therefore need a specific applicability statement indicating when the mechanism can (and can not) be used. Enabling this, and ensuring correct interactions with the stack, implies much more than simply disabling the checksum algorithm for specific packets at the transport interface. The IETF should carefully consider constraints on sanctioning the use of any new transport mode. If this is specified and widely available, it may be expected to be used by applications that are @@ -948,23 +953,24 @@ has actually been corrupted. o A method has been proposed that uses a new (to be defined) IPv6 Destination Options Header to provide an end-to-end validation check at the network layer. This would allow an endpoint to verify delivery to an appropriate end point, but would also require IPv6 nodes to correctly handle the additional header, and would require changes to middlebox behavior (e.g. when used with a NAT that always adjusts the checksum value). - o UDP modified to disable checksum processing[UDPZ]. This requires - no checksum calculation, but would require constraints on - appropriate usage and updates to end-points and middleboxes. + o UDP modified to disable checksum processing + [I-D.ietf-6man-udpchecksums]. This requires no checksum + calculation, but would require constraints on appropriate usage + and updates to end-points and middleboxes. o IP-in-IP tunneling. As this method completely dispenses with a transport protocol in the outer-layer it has reduced overhead and complexity, but also reduced functionality. There is no outer checksum over the packet and also no ports to perform demultiplexing between different tunnel types. This reduces the information available upon which a load balancer may act. These options are compared and discussed further in the following sections. @@ -1106,21 +1112,21 @@ traversal, no multiplexing support, and currently poor load balancing support that could improve over time. UDP-Lite: A medium complexity encapsulation, with good multiplexing support, limited middlebox traversal, but possible to improve over time, currently poor load balancing support that could improve over time, in most cases requiring application level negotiation and validation. The delta-checksum is an optimization in the processing of UDP, as - such > it exhibits some of the drawbacks of using regular UDP. + such it exhibits some of the drawbacks of using regular UDP. The remaining proposals may be described in similar terms: Zero-Checksum: A low complexity encapsulation, with good multiplexing support, limited middlebox traversal that could improve over time, good load balancing support, in most cases requiring application level negotiation and validation. UDPTT: A medium complexity encapsulation, with good multiplexing support, limited middlebox traversal, but possible to improve over @@ -1151,28 +1157,28 @@ balancing, then IP-in-IP tunneling is the simplest. If one wants strengthened error detection, but with currently limited middlebox traversal and load-balancing. UDP-Lite is appropriate. UDP Zero- checksum addresses another set of constraints, low complexity and a need for load balancing from the current Internet, providing it can live with currently limited middlebox traversal. Techniques for load balancing and middlebox traversal do continue to evolve. Over a long time, developments in load balancing have good potential to improve. This time horizon is long since it requires - end-point updates to get full benefit. The challenges of middlebox - traversal are also expected to change with time, as device - capabilities evolve. Middleboxes are very prolific with a larger - proportion of end-user ownership, and therefore may be expected to - take long time cycles to evolve. One potential advantage is that the - deployment of IPv6 capable middleboxes are still in its initial phase - and the quicker zero-checksum becomes standardized the fewer boxes - will be non-compliant. + both load balancer and end-point updates to get full benefit. The + challenges of middlebox traversal are also expected to change with + time, as device capabilities evolve. Middleboxes are very prolific + with a larger proportion of end-user ownership, and therefore may be + expected to take long time cycles to evolve. One potential advantage + is that the deployment of IPv6 capable middleboxes are still in its + initial phase and the quicker zero-checksum becomes standardized the + fewer boxes will be non-compliant. Thus, the question of whether to allow UDP with a zero-checksum for IPv6 under reasonable constraints, is therefore best viewed as a trade-off between a number of more subjective questions: o Is there sufficient interest in zero-checksum with the given constraints (summarised below)? o Are there other avenues of change that will resolve the issue in a better way and sufficiently quickly ? @@ -1336,21 +1342,21 @@ Brian Haberman, Brian Carpenter, Magaret Wasserman, Lars Eggert, others in the TSV directorate. Thanks also to: Remi Denis-Courmont, Pekka Savola and many others who contributed comments and ideas via the 6man, behave, lisp and mboned lists. 8. IANA Considerations - This document does not require IANA considerations. + This document does not require any actions by IANA. 9. Security Considerations Transport checksums provide the first stage of protection for the stack, although they can not be considered authentication mechanisms. These checks are also desirable to ensure packet counters correctly log actual activity, and can be used to detect unusual behaviours. 10. References @@ -1371,27 +1377,32 @@ 10.2. Informative References [AMT] Internet draft, draft-ietf-mboned-auto-multicast-10, "Automatic IP Multicast Without Explicit Tunnels (AMT)", March 2010. [ECMP] "Using the IPv6 flow label for equal cost multipath routing in tunnels (draft-carpenter-flow-ecmp)". + [I-D.ietf-6man-udpchecksums] + Eubanks, M., "UDP Checksums for Tunneled Packets", + draft-ietf-6man-udpchecksums-00 (work in progress), + March 2011. + [I-D.ietf-intarea-tunnels] Touch, J. and M. Townsley, "Tunnels in the Internet Architecture", draft-ietf-intarea-tunnels-00 (work in progress), March 2010. - [LISP] Internet draft, draft-farinacci-lisp-12.txt, "Locator/ID - Separation Protocol (LISP)", March 2009. + [LISP] D. Farinacci et al, "Locator/ID Separation Protocol + (LISP)", March 2009. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the Internet checksum", RFC 1141, January 1990. [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via Incremental Update", RFC 1624, May 1994. @@ -1423,26 +1434,24 @@ November 2008. [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009. [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009. [Sigcomm2000] - http://conferences.sigcomm.org/sigcomm/2000/conf/abstract/ - 9-1.htm, "When the CRC and TCP Checksum Disagree", 2000. - - [UDPTT] "The UDP Tunnel Transport mode", Feb 2010. + Jonathan Stone and Craig Partridge , "When the CRC and TCP + Checksum Disagree", 2000. - [UDPZ] "UDP Checksums for Tunneled Packets", (Oct 2009. + [UDPTT] G Fairhurst, "The UDP Tunnel Transport mode", Feb 2010. Appendix A. Document Change History {RFC EDITOR NOTE: This section must be deleted prior to publication} Individual Draft 00 This is the first DRAFT of this document - It contains a compilation of various discussions and contributions from a variety of IETF WGs, including: mboned, tsv, 6man, lisp, and behave. This includes contributions from Magnus with text on RTP, and various updates. @@ -1479,26 +1488,23 @@ of the document. * A new section comparing the results have been added. * The constraints list has been significantly altered by removing some and rewording other constraints. * This contains other significant language updates to clarify the intent of this draft. - **TO BE DONE ** - - * This version requires review from proponents and opponents to - the UDP zero checksum proposal. + Working Group Draft 03 - * + * Editorial updates Authors' Addresses Godred Fairhurst University of Aberdeen School of Engineering Aberdeen, AB24 3UE, Scotland, UK Phone: