--- 1/draft-ietf-6man-udpzero-10.txt 2013-02-21 15:23:19.295790583 +0100 +++ 2/draft-ietf-6man-udpzero-11.txt 2013-02-21 15:23:19.363791171 +0100 @@ -1,129 +1,136 @@ Internet Engineering Task Force G. Fairhurst Internet-Draft University of Aberdeen Intended status: Standards Track M. Westerlund -Expires: July 25, 2013 Ericsson - January 21, 2013 +Expires: August 25, 2013 Ericsson + February 21, 2013 Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums - draft-ietf-6man-udpzero-10 + draft-ietf-6man-udpzero-11 Abstract This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations and examines the role of the IPv6 UDP transport - checksum. An appendix presents a summary of the trade-offs that were - considered in evaluating the safety of the update to RFC 2460 that - updates use of the UDP checksum with IPv6. + checksum. The document also identifies issues and constraints for + deployment on network paths that include middleboxes. An appendix + presents a summary of the trade-offs that were considered in + evaluating the safety of the update to RFC 2460 that updates use of + the UDP checksum with IPv6. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 July 25, 2013. + This Internet-Draft will expire on August 25, 2013. Copyright Notice Copyright (c) 2013 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 described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 6 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 - 1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 6 - 1.3.1. Motivation for new approaches . . . . . . . . . . . . 7 - 1.3.2. Reducing forwarding cost . . . . . . . . . . . . . . . 7 - 1.3.3. Need to inspect the entire packet . . . . . . . . . . 8 - 1.3.4. Interactions with middleboxes . . . . . . . . . . . . 8 - 1.3.5. Support for load balancing . . . . . . . . . . . . . . 9 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 5 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 5 + 1.3.1. Motivation for new approaches . . . . . . . . . . . . 6 + 1.3.2. Reducing forwarding cost . . . . . . . . . . . . . . . 6 + 1.3.3. Need to inspect the entire packet . . . . . . . . . . 7 + 1.3.4. Interactions with middleboxes . . . . . . . . . . . . 7 + 1.3.5. Support for load balancing . . . . . . . . . . . . . . 8 2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 9 - 2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 10 - 2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 10 - 2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 11 - 3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 11 + 2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 9 + 2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 9 + 2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 10 + 2.4. Relation to UDP-Lite and UDP with checksum . . . . . . . . 10 + 3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 12 3.1. Effect of packet modification in the network . . . . . . . 12 - 3.1.1. Corruption of the destination IP address . . . . . . . 13 - 3.1.2. Corruption of the source IP address . . . . . . . . . 13 - 3.1.3. Corruption of Port Information . . . . . . . . . . . . 14 - 3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 15 - 3.1.5. Corruption of Fragmentation Information . . . . . . . 16 - 3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 18 - 3.3. Validating the network path . . . . . . . . . . . . . . . 18 - 3.4. Applicability of method . . . . . . . . . . . . . . . . . 19 - 3.5. Impact on non-supporting devices or applications . . . . . 20 + 3.1.1. Corruption of the destination IP address . . . . . . . 14 + 3.1.2. Corruption of the source IP address . . . . . . . . . 14 + 3.1.3. Corruption of Port Information . . . . . . . . . . . . 16 + 3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 16 + 3.1.5. Corruption of Fragmentation Information . . . . . . . 17 + 3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 19 + 3.3. Validating the network path . . . . . . . . . . . . . . . 20 + 3.4. Applicability of method . . . . . . . . . . . . . . . . . 21 + 3.5. Impact on non-supporting devices or applications . . . . . 21 4. Constraints on implementation of IPv6 nodes supporting - zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 20 - 5. Requirements on usage of the zero UDP checksum . . . . . . . . 22 - 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 + zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 22 + 5. Requirements on usage of the zero UDP checksum . . . . . . . . 23 + 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 + Appendix A. Evaluation of proposal to update RFC 2460 to - support zero checksum . . . . . . . . . . . . . . . . 28 - A.1. Alternatives to the Standard Checksum . . . . . . . . . . 28 - A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 30 - A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 30 - A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 31 - A.2.3. Ingress and Egress Performance Implications . . . . . 31 - A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 32 - A.2.5. Corruption Detection Strength . . . . . . . . . . . . 32 - A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 33 - Appendix B. Document Change History . . . . . . . . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 + support zero checksum . . . . . . . . . . . . . . . . 31 + A.1. Alternatives to the Standard Checksum . . . . . . . . . . 31 + A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 32 + A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 33 + A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 33 + A.2.3. Ingress and Egress Performance Implications . . . . . 34 + A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 34 + A.2.5. Corruption Detection Strength . . . . . . . . . . . . 35 + A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 35 + Appendix B. Document Change History . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction 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 RFC 2460 mandates use of a calculated UDP checksum, i.e. a non-zero value, due to the lack of an IPv6 header checksum. - Algorithms for checksum computation are described in [RFC1071]. + The inclusion of the pseudo header in the checksum computation + provides a statistical check that datagrams have been delivered to + the intended IPv6 destination node. Algorithms for checksum + computation are described in [RFC1071]. The lack of a possibility to use an IPv6 datagram with a zero UDP checksum 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 UDP checksum using IPv4. The design of IPv6 raises different issues when considering the safety of using a UDP checksum with IPv6. These issues can significantly affect applications, both when an endpoint is the intended user and when an innocent bystander (when a packet is received by a different endpoint to that intended). @@ -220,34 +226,39 @@ o Reducing forwarding costs, motivated by redundancy present in the encapsulated packet header, since in tunnel encapsulations, payload integrity and length verification may be provided by higher layer encapsulations (often using the IPv4, UDP, UDP-Lite, or TCP checksums). o Eliminating a need to access the entire packet when forwarding the packet by a tunnel endpoint. o Enhancing ability to traverse middleboxes, especially Network - Address Translators, NATs. + Address Translators, NATs. However, use of the zero UDP checksum + does not fully fulfill this need, because only certain classes of + middleboxes, (i.e. ones that do not modify or evaluate the UDP + checksum) will support zero UDP checksum traffic, other + middleboxes will require an update to support this traffic. o A desire to use the port number space to enable load-sharing. 1.3.2. Reducing forwarding cost It is a common requirement to terminate a large number of tunnels on a single router/host. The processing cost per tunnel includes both - state (memory requirements) and per-packet processing. + state (memory requirements) and per-packet processing at the tunnel + ingress and egress. Automatic IP Multicast Tunneling, known as AMT [I-D.ietf-mboned-auto-multicast] currently specifies UDP as the transport protocol for packets carrying tunneled IP multicast - packets. The current specification for AMT requires that the UDP + packets. The current specification for AMT states that the UDP checksum in the outer packet header should be zero (see Section 6.6 of [I-D.ietf-mboned-auto-multicast]). This argues that the computation of an additional checksum is an unwarranted burden on nodes implementing lightweight tunneling protocols when an inner packet is already adequately protected, . 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. @@ -260,27 +271,30 @@ 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 tunnel end-points where this off-loading is not available and unlikely to become available in the near future. 1.3.3. Need to inspect the entire packet The currently-deployed hardware in many routers uses a fast-path processing that only provides the first n bytes of a packet to the - forwarding engine, where typically n <= 128. This prevents fast - processing of a transport checksum over an entire (large) packet. - Hence the currently defined IPv6 UDP checksum is poorly suited to use - within a router that is unable to access the entire packet and does - not provide checksum-offloading. Thus enabling checksum calculation - over the complete packet can impact router design, performance - improvement, energy consumption and/or cost. + forwarding engine, where typically n <= 128. + + When this design is used to support a tunnel ingress and egress, it + prevents fast processing of a transport checksum over an entire + (large) packet. Hence the currently defined IPv6 UDP checksum is + poorly suited to use within a router that is unable to access the + entire packet and does not provide checksum-offloading. Thus + enabling checksum calculation over the complete packet can impact + router design, performance improvement, energy consumption and/or + cost. 1.3.4. Interactions with middleboxes In IPv4, UDP-encapsulation may be desirable for NAT traversal, since UDP support is commonly provided. It is also necessary due to the almost ubiquitous deployment of IPv4 NATs. There has also been discussion of NAT for IPv6, although not for the same reason as in IPv4. If IPv6 NAT becomes a reality they hopefully do not present the same protocol issues as for IPv4. If NAT is defined for IPv6, it should take into consideration the use of a zero UDP checksum. @@ -299,32 +313,33 @@ capabilities to improve over time. We also note that deployment of IPv6-capable middleboxes is still in its initial phases. Thus, it might be that the number of non-updated boxes quickly become a very small percentage of the deployed middleboxes. 1.3.5. Support for load balancing The UDP port number fields have been used as a basis to design load- balancing solutions for IPv4. This approach has also been leveraged for IPv6. An alternate method would be to utilise the IPv6 Flow - Label as a basis for entropy for load balancing. This would have the - desirable effect of releasing IPv6 load-balancing devices from the - need to assume semantics for the use of the transport port field and - also works for all type of transport protocols. + Label [RFC6437] as a basis for entropy for load balancing. This + would have the desirable effect of releasing IPv6 load-balancing + devices from the need to assume semantics for the use of the + transport port field and also works for all type of transport + protocols. - This use of the flow-label is consistent with the intended use, - although further clarity may be needed to ensure the field can be - consistently used for this purpose, (e.g. the updated IPv6 Flow Label - [RFC6438] and Equal-Cost Multi-Path routing, ECMP [RFC6437]). Router - vendors could be encouraged to start using the IPv6 Flow Label as a - part of the flow hash, providing support for ECMP without requiring - use of UDP. + This use of the flow-label for load balancing is consistent with the + intended use, although further clarity was needed to ensure the field + can be consistently used for this purpose, therefore an updated IPv6 + Flow Label [RFC6437] and Equal-Cost Multi-Path routing usage, (ECMP) + [RFC6438] was produced. Router vendors could be encouraged to start + using the IPv6 Flow Label as a part of the flow hash, providing + support for ECMP without requiring use of UDP. However, the method for populating the outer IPv6 header with a value for the flow label is not trivial: If the inner packet uses IPv6, then the flow label value could be copied to the outer packet header. However, many current end-points set the flow label to a zero value (thus no entropy). The ingress of a tunnel seeking to provide good entropy in the flow label field would therefore need to create a random flow label value and keep corresponding state, so that all packets that were associated with a flow would be consistently given the same flow label. Although possible, this complexity may not be @@ -349,21 +364,21 @@ 2.1. UDP with Standard Checksum UDP [RFC0768] with standard checksum behaviour, as defined in RFC 2460, has already been discussed. UDP usage guidelines are provided in [RFC5405]. 2.2. UDP-Lite UDP-Lite [RFC3828] offers an alternate transport to UDP, specified as - a proposed standard, RFC 3828. A MIB is defined in RFC 5097 and + a proposed standard, RFC 3828. A MIB is defined in [RFC5097] and unicast usage guidelines in [RFC5405]. There is at least one open source implementation as a part of the Linux kernel since version 2.6.20. 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, with the exception that it uses a different value in the Next Header field in the IPv6 header. Errors/ @@ -412,29 +427,85 @@ From the end-to-end perspective, the principal difference is that the network-layer Next Header field identifies a separate transport, which reduces the probability that corruption could result in the packet being delivered to the wrong endpoint or application. Specifically, packets are only delivered to protocol modules that process a specific Next Header value. The Next Header field therefore provides a first-level check of correct demultiplexing. In contrast, the UDP port space is shared by many diverse applications and therefore UDP demultiplexing relies solely on the port numbers. +2.4. Relation to UDP-Lite and UDP with checksum + + The operation of IPv6 with UDP with a zero-checksum is not the same + as IPv4 with UDP with a zero-checksum. Protocol designers should not + be fooled into thinking the two are the same. The requirements below + list a set of additional considerations. + + Where possible, existing general tunnel encapsulations, such as GRE, + IP-in-IP, should be used. This section assumes that such existing + tunnel encapsulations do not offer the functionally required to + satisfy the protocol designer's goals. The section considers the + standardized alternative solutions, rather than the full set of ideas + evaluated in Appendix A. The alternatives to UDP with a zero + checksum are UDP with a (calculated) checksum, and UDP-Lite. + + UDP with a checksum has the advantage of close to universal support + in both endpoints and middleboxes. It also provides statistical + verification of delivery to the intended destination (address and + port). However, some classes of device have limited support for + calculation of a checksum that covers a full datagram. For these + devices, this can incur significant processing cost (e.g. requiring + processing in the router slow-path) and can hence reduce capacity or + fail to function. + + UDP-Lite has the advantage of using a checksum that is calculated + only over the pseudo header and the UDP header. This provides a + statistical verification of delivery to the intended destination + (address and port). The checksum can be calculated without access to + the datagram payload, only requiring access to the part to be + protected. A drawback is that UDP-Lite has currently limited support + in both end-points (i.e. is not supported on all operating system + platforms) and middleboxes (that require support for the UDP-Lite + header type). A path verification method is therefore recommended. + + IPv6 and UDP with a zero-checksum can also be used by nodes that do + not permit calculation of a payload checksum. Many existing classes + of middleboxes do not verify or change the transport checksum. For + these middleboxes, IPv6 with a zero UDP checksum is expected to + function where UDP-Lite would not. However, support for the zero UDP + checksum in middleboxes that do change or verify the checksum is + currently limited, and this may result in datagrams with a zero UDP + checksum being discarded, therefore a path verification method is + recommended. + + There are sets of constrains for which no solution exist: A protocol + designer that needs to originate or receive datagrams on a device + that can not efficiently calculate a checksum over a full datagram + and also needs these packets to pass through a middlebox that + verifies or changes a UDP checksum, but does not support a zero UDP + checksum, can not use the zero UDP checksum method. Similarly, one + that originates datagrams on a device with UDP-Lite support, but + needs the packets to pass through a middlebox that does not support + UDP-Lite, can not use UDP-Lite. For such cases, there is no optimal + solution and the current recommendation is to use or fall-back to + using UDP with full checksum coverage. + 3. Issues Requiring Consideration This informative section evaluates issues around the proposal to update IPv6 [RFC2460], to enable the UDP transport checksum to be set to zero. Some of the identified issues are shared with other protocols already in use. The section also provides background to the requirements and recommendations that follow. - The decision by RFC 2460 to omit an integrity check at the network + The decision in RFC 2460 to omit an integrity check at the network level meant that the IPv6 transport checksum was overloaded with many functions, including validating: o the endpoint address was not corrupted within a router, i.e., a packet was intended to be received by this destination and validate that the packet does not consist of a wrong header spliced to a different payload; o that extension header processing is correctly delimited - i.e., the start of data has not been corrupted. In this case, reception @@ -455,31 +526,70 @@ In IPv6, these checks occur within the endpoint stack using the UDP checksum information. An IPv6 node also relies on the header information to determine whether to send an ICMPv6 error message [RFC4443] and to determine the node to which this is sent. Corrupted information may lead to misdelivery to an unintended application socket on an unexpected host. 3.1. Effect of packet modification in the network - IP packets may be corrupted as they traverse an Internet path. - Evidence has been presented [Sigcomm2000] to show that this was once - an issue with IPv4 routers, and occasional corruption could result - from bad internal router processing in routers or hosts. These - errors are not detected by the strong frame checksums employed at the - link-layer [RFC3819]. There is no current evidence that such cases - are rare in the modern Internet, nor that they may not be applicable - to IPv6. It therefore seems prudent not to relax this constraint. - The emergence of low-end IPv6 routers and the proposed use of NAT - with IPv6 further motivate the need to protect from this type of - error. + IP packets may be corrupted as they traverse an Internet path. Older + evidence in "When the CRC and TCP Checksum Disagree" [Sigcomm2000] + show that this was once an issue in year 2000 with IPv4 routers, and + occasional corruption could result from bad internal router + processing in routers or hosts. These errors are not detected by the + strong frame checksums employed at the link-layer [RFC3819]. During + the development of this document in 2009, individuals provided + reports of observed rates for received UDP datagrams using IPv4 where + the UDP checksum had been detected as corrupt. These rates where as + high as 1.39E-4 for some paths, but also close to zero for some other + paths. + + There is extensive experience of deployment using tunnel protocols in + well-managed networks (e.g. corporate networks or service provider + core networks). This has shown the robustness of methods such as PWE + and MPLS that do not employ a transport protocol checksum and have + not specified mechanisms to protect from corruption of the + unprotected headers (such as the VPN Identifier in MPLS). Reasons + for the robustness may include: + + o A reduced probability of corruption on paths through well-managed + networks. + + o IP form the majority of the inner traffic carried by these tunnel. + Hence from a transport perspective, endpoint verification is + already being performed when processing a received IPv4 packet or + by the transport pseudo-header for an IPv6 packet. This update to + UDP does not change this behaviour. + + o In certain cases, a combination of additional filtering (e.g. + filter of a MAC destination address in a L2 tunnel) significantly + reduces the probability of final mis-delivery to the IP stack. + + o The tunnel protocols did not use a UDP transport header, any + corruption is therefore unlikely to result in misdelivery to + another UDP-based application. This concern is specific to the + use of UDP with IPv6. + + While this experience can guide the present recommendations, any + update to UDP must preserve operation in the general Internet. This + is heterogeneous and can include links and systems of very varying + characteristics. Transport protocols used by hosts need to be + designed with this in mind, especially when there is need to traverse + edge networks, where middlebox deployments are common. + + For the general Internet, there is no current evidence that + corruption is rare, nor that this may not be applicable to IPv6. It + therefore seems prudent not to relax checks on misdelivery . The + emergence of low-end IPv6 routers and the proposed use of NAT with + IPv6 further motivate the need to protect from misdelivery. Corruption in the network may result in: o A datagram being misdelivered to the wrong host/router or the wrong transport entity within an endpoint. Such a datagram needs to be discarded; o A datagram payload being corrupted, but still delivered to the intended host/router transport entity. Such a datagram needs to be either discarded or correctly processed by an application that @@ -496,40 +606,44 @@ The following sections examine the impact of modifying each of these header fields. 3.1.1. Corruption of the destination IP address An IPv6 endpoint destination address could be modified in the network (e.g. corrupted by an error). This is not a concern for IPv4, because the IP header checksum will result in this packet being discarded by the receiving IP stack. Such modification in the network can not be detected at the network layer when using IPv6. + Detection of this corruption by a UDP receiver relies on the IPv6 + pseudo header incorporated in the transport checksum. There are two possible outcomes: o Delivery to a destination address that is not in use (the packet will not be delivered, but could result in an error report); o Delivery to a different destination address. This modification will normally be detected by the transport checksum, resulting in silent discard. Without a computed checksum, the packet would be passed to the endpoint port demultiplexing function. If an application is bound to the associated ports, the packet payload will be passed to the application (see the subsequent section on port processing). 3.1.2. Corruption of the source IP address This section examines what happens when the source address is corrupted in transit. This is not a concern in IPv4, because the IP header checksum will normally result in this packet being discarded - by the receiving IP stack. + by the receiving IP stack. Detection of this corruption by a UDP + receiver relies on the IPv6 pseudo header incorporated in the + transport checksum. Corruption of an IPv6 source address does not result in the IP packet being delivered to a different endpoint protocol or destination address. If only the source address is corrupted, the datagram will likely be processed in the intended context, although with erroneous origin information. When using Unicast Reverse Path Forwarding [RFC2827], a change in address may result in the router discarding the packet when the route to the modified source address is different to that of the source address of the original packet. @@ -937,21 +1052,31 @@ the reported packet actually originated from the node, before acting upon the information (e.g. validating the address and port numbers in the ICMPv6 message body). 5. Requirements on usage of the zero UDP checksum This section is an applicability statement that identifies requirements and recommendations for protocols and tunnel encapsulations that are transported over an IPv6 transport flow (e.g. tunnel) that does not perform a UDP checksum calculation to verify - the integrity at the transport endpoints. + the integrity at the transport endpoints. Before deciding to use the + zero UDP checksum and loose the integrity verification provided, a + protocol developer should seriously consider if they can use + checksummed UDP packets or UDP-Lite [RFC3828], because IPv6 with a + zero UDP checksum is not equivalent in behavior to IPv4 with zero UDP + checksum. + + The requirements and recommendations for protocols and tunnel + encapsulations using an IPv6 transport flow that does not perform a + UDP checksum calculation to verify the integrity at the transport + endpoints are: 1. Transported protocols that enable the use of zero UDP checksum MUST only enable this for a specific port or port-range. This needs to be enabled at the sending and receiving endpoints for a UDP flow. 2. An integrity mechanism is always RECOMMENDED at the transported protocol layer to ensure that corruption rates of the delivered payload is not increased (e.g. the inner-most packet of a UDP tunnel). A mechanism that isolates the causes of corruption @@ -1009,39 +1134,71 @@ are outside a configured range. 10. When a middlebox forwards an IPv6 UDP flow containing datagrams with both a zero and standard UDP checksum, the middlebox MUST NOT maintain separate state for flows depending on the value of their UDP checksum field. (This requirement is necessary to enable a sender that always calculates a checksum to communicate via a middlebox with a remote endpoint that uses a zero UDP checksum.) + Special considerations are required when designing a UDP tunnel + protocol, where the tunnel ingress or egress may be a router that may + not have access to the packet payload. When the node is acting as a + host (i.e., sending or receiving a packet addressed to itself), the + checksum processing is similar to other hosts. However, when the + node (e.g. a router) is acting as a tunnel ingress or egress that + forwards a packet to or from a UDP tunnel, there may be restricted + access to the packet payload. This prevents calculating (or + verifying) a UDP checksum. In this case, the tunnel protocol may use + a zero UDP checksum and must: + + o Ensure that tunnel ingress and tunnel egress router are both + configured to use a zero UDP checksum. For example, this may + include ensuring that hardware checksum offloading is disabled. + + o The tunnel operator must ensure that middleboxes on the network + path are updated to support use of a zero UDP checksum. + + o A tunnel egress should implement appropriate security techniques + to protect from overload, including source address filtering to + prevent traffic injection by an attacker, and rate-limiting of any + packets that incur additional processing, such as UDP datagrams + used for control functions that require verification of a + calculated checksum to verify the network path. Usage of common + control traffic for multiple tunnels between a pair of nodes can + assist in reducing the number of packets to be processed. + 6. Summary - This document examines the role of the UDP transport checksum when - used with IPv6. It presents a summary of the trade-offs in - evaluating the safety of updating RFC 2460 to permit an IPv6 endpoint - to use a zero UDP checksum field to indicate that no checksum is - present. + This document provides an applicability statement for the use of UDP + transport checksums with IPv6. - The use of UDP with a zero UDP checksum has merits for some - applications, such as tunnel encapsulation, and is widely used in - IPv4. However, there are different dangers for IPv6: There is an - increased risk of corruption and misdelivery when using zero UDP - checksum in IPv6 compared to using IPv4 due to the lack of an IPv6 - header checksum. Thus, applications need to re-evaluate the risks of - enabling use of a zero UDP checksum and consider a solution that at - least provides the same delivery protection as for IPv4, for example - by utilizing UDP-Lite, or by enabling the UDP checksum. The use of - checksum off-loading may help alleviate the checksum processing cost - and permit use of a checksum using method defined in RFC 2460. + It examines the role of the UDP transport checksum when used with + IPv6 and presents a summary of the trade-offs in evaluating the + safety of updating RFC 2460 to permit an IPv6 endpoint to use a zero + UDP checksum field to indicate that no checksum is present. + + Application designers should first examine whether their transport + goals may be met using standard UDP (with a calculated checksum) or + by using UDP-Lite. The use of UDP with a zero UDP checksum has + merits for some applications, such as tunnel encapsulation, and is + widely used in IPv4. However, there are different dangers for IPv6: + There is an increased risk of corruption and misdelivery when using + zero UDP checksum in IPv6 compared to using IPv4 due to the lack of + an IPv6 header checksum. Thus, applications need to evaluate the + risks of enabling use of a zero UDP checksum and consider a solution + that at least provides the same delivery protection as for IPv4, for + example by utilizing UDP-Lite, or by enabling the UDP checksum. The + use of checksum off-loading may help alleviate the cost of checksum + processing and permit use of a checksum using method defined in RFC + 2460. Tunnel applications using UDP for encapsulation can in many cases use a zero UDP checksum without significant impact on the corruption rate. A well-designed tunnel application should include consistency checks to validate the header information encapsulated with a received packet. In most cases, tunnels encapsulating IP packets can rely on the integrity protection provided by the transported protocol (or tunneled inner packet). When correctly implemented, such an endpoint will not be negatively impacted by omission of the transport-layer checksum. Recursive tunneling and fragmentation is a @@ -1065,83 +1221,95 @@ the reduced checksum for UDP-Lite when used with IPv6. The transport of recursive tunneling and the use of fragmentation pose difficult issues that need to be considered in the design of tunnel protocols. There is an increased risk of an error in the inner-most packet when fragmentation when several layers of tunneling and several different reassembly processes are run without verification of correctness. This requires extra thought and careful consideration in the design of transported tunnels. - The use of the updated method must consider the implications on + Any use of the updated method must consider the implications on firewalls, NATs and other middleboxes. It is not expected that IPv6 NATs handle IPv6 UDP datagrams in the same way that they handle IPv4 - UDP datagrams. This possibly reduces the need to update the - checksum. Firewalls are intended to be configured, and therefore may - need to be explicitly updated to allow new services or protocols. - IPv6 middlebox deployment is not yet as prolific as it is in IPv4, - and therefore new devices are expected to follow the methods - specified in this document. + UDP datagrams. In many deployed cases this will require an update to + support an IPv6 zero UDP checksum. Firewalls are intended to be + configured, and therefore may need to be explicitly updated to allow + new services or protocols. IPv6 middlebox deployment is not yet as + prolific as it is in IPv4, and therefore new devices are expected to + follow the methods specified in this document. Each application should consider the implications of choosing an IPv6 transport that uses a zero UDP checksum, and consider whether other standard methods may be more appropriate, and may simplify application design. 7. Acknowledgements Brian Haberman, Brian Carpenter, Margaret Wasserman, Lars Eggert, - others in the TSV directorate. Barry Leiba, Ronald Bonica and - Stewart Bryant are thanked for resulting in a document with much - greater applicability. Thanks to P.F. Chimento for careful review - and editorial corrections. + others in the TSV directorate. Barry Leiba, Ronald Bonica, Pete + Resnick, and Stewart Bryant are thanked for resulting in a document + with much greater applicability. Thanks to P.F. Chimento for careful + review and editorial corrections. Thanks also to: Remi Denis-Courmont, Pekka Savola, Glen Turner, and many others who contributed comments and ideas via the 6man, behave, lisp and mboned lists. 8. 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. Depending on the hardware design, the processing requirements may differ for tunnels that have a zero UDP checksum and those that calculate a checksum. This processing overhead may need to be considered when deciding whether to enable a tunnel and to determine - an acceptable rate for transmission. + an acceptable rate for transmission. This can become a security risk + for designs that can handle a significantly larger number of packets + with zero UDP checksums compared to datagrams with a non-zero + checksum, such as tunnel egress. An attacker could attempt to inject + non-zero checksummed UDP packets into a tunnel forwarding zero + checksum UDP packets and cause overload in the processing of the non- + zero checksums, e.g. if this happens in a routers slow path. + Protection mechanisms should therefore be employed when this threat + exists. Protection may include source address filtering to prevent + an attacker injecting traffic, as well as throttling the amount of + non-zero checksum traffic. The latter may impact the function of the + tunnel protocol. Transmission of IPv6 packets with a zero UDP checksum could reveal additional information to an on-path attacker to identify the operating system or configuration of a sending node. There is a need - to probe the network path to determine whether the path supports - using IPv6 packets with a zero UDP checksum. The details of the - probing mechanism may differ for different tunnel encapsulations and - if visible in the network (e.g. if not using IPsec in encryption + to probe the network path to determine whether the current path + supports using IPv6 packets with a zero UDP checksum. The details of + the probing mechanism may differ for different tunnel encapsulations + and if visible in the network (e.g. if not using IPsec in encryption mode) could reveal additional information to an on-path attacker to identify the type of tunnel being used. IP-in-IP or GRE tunnels offer good traversal of middleboxes that have not been designed for security, e.g. firewalls. However, firewalls may be expected to be configured to block general tunnels as they present a large attack surface. This applicability statement therefore permits this method to be enabled only for specific ranges of ports. - When enabled, nodes and middleboxes must forward received UDP - datagrams that have either a calculated checksum or a zero checksum. + When the zero UDP checksum mode is enabled for a range of ports, + nodes and middleboxes must forward received UDP datagrams that have + either a calculated checksum or a zero checksum. 10. References 10.1. Normative References [I-D.ietf-6man-udpchecksums] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", draft-ietf-6man-udpchecksums-07 (work in progress), January 2013. @@ -1200,20 +1368,23 @@ G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007. + [RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite + protocol", RFC 5097, January 2008. + [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, 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. @@ -1400,50 +1571,54 @@ o The solution with the best deployability is regular UDP. This requires no changes and has good middlebox traversal characteristics. o The next easiest to deploy is the delta checksum solution. This does not modify the protocol on the wire and only needs changes in tunnel ingress. o IP-in-IP tunnels should not require changes to the end-points, but - raise issues when traversing firewalls and other security-type - devices, which are expected to require updates. + raise issues when traversing firewalls and other security devices, + which are expected to require updates. o Ignoring the checksum on reception will require changes at both end-points. The never ceasing risk of path failure requires additional checks to ensure this solution is robust and will require changes or additions to the tunnel control protocol to negotiate support and validate the path. - o The remaining solutions offer similar deployability. UDP-Lite - requires support at both end-points and in middleboxes. UDPTT and - the zero UDP checksum method with or without an extension header - require support at both end-points and in middleboxes. UDP-Lite, - UDPTT, and the zero UDP checksum method and use of extension - headers may additionally require changes or additions to the - tunnel control protocol to negotiate support and path validation. + o The remaining solutions (including the zero checksum method) offer + similar deployability. UDP-Lite requires support at both end- + points and in middleboxes. UDPTT and the zero UDP checksum method + with or without an extension header require support at both end- + points and in middleboxes. UDP-Lite, UDPTT, and the zero UDP + checksum method and use of extension headers may additionally + require changes or additions to the tunnel control protocol to + negotiate support and path validation. A.2.5. Corruption Detection Strength The standard UDP checksum and the delta checksum can both provide some verification at the tunnel egress. This can significantly reduce the probability that a corrupted inner packet is forwarded. UDP-Lite, UDPTT and the extension header all provide some verification against corruption, but do not verify the inner packet. They only provide a strong indication that the delivered packet was - intended for the tunnel egress and was correctly delimited. The - methods using a zero UDP checksum, ignoring the UDP checksum on + intended for the tunnel egress and was correctly delimited. + + The methods using a zero UDP checksum, ignoring the UDP checksum on reception and IP-and-IP encapsulation all provide no verification that a received datagram was intended to be processed by a specific tunnel egress or that the inner encapsulated packet was correct. + Section 3.1 discusses experience using specific protocols in well- + managed networks. A.2.6. Comparison Summary The comparisons above may be summarised as "there is no silver bullet that will slay all the issues". One has to select which down side(s) can best be lived with. Focusing on the existing solutions, this can be summarized as: Regular UDP: The method defined in RFC 2460 has good middlebox traversal and load balancing and multiplexing, requiring a @@ -1611,21 +1785,21 @@ for noting these.Group Draft 05. Working Group Draft 06 * Resubmission to keep draft alive (spelling updated from 05). Working Group Draft 07 * Interim Version - * Submission after IESG Feedback + * Submission after IESG Feedback Added * Updates to enable the document to become a PS Applicability Statement Working Group Draft 08 * First Version written as a PS Applicability Statement * Changes to reflect decision to update RFC 2460, rather than recommend decision @@ -1646,31 +1820,51 @@ * Clarified that full checksum is required in security considerations, and therefore noting that full checksum should not be treated as an attack - consistent with remainder of document. * Added mention that API can set a mode in transport stack - to link to similar statement in RFC 2460 update. * Fixed typos. - Working Group Draft 08 + Working Group Draft 10 * Submission to correct unwanted removal of text from section 5 bullets 5-7 by GF. * Replaced section 5 text with the text from 08, and reapplied the editorial correction. * Note to reviewers: Please compare this revision with -08 used in the IETF LC). + Working Group Draft 11 + + * Added REF for 5097 (Noted by S.Turner) + + * Added text in response to P. Resnick on place where checksum is + calculated. + + * Added text to note experience with MPLS/PWE; Appendix updated + to refer to this (S. Bryant) + + * Added text in response to P.Resnick's 2nd comments. + + * Request to make UDP-Lite more clearly recommended (J Touch, + P.Resnick) + + * Added considerations around usage of zero checksum in routers. + + * Added text in response to Stewart Bryant's comments on router + requirements. + Authors' Addresses Godred Fairhurst University of Aberdeen School of Engineering Aberdeen, AB24 3UE Scotland, UK Email: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk/users/gorry