Internet Engineering Task Force (IETF) M. Eubanks Request for Comments: 6935 AmericaFree.TV LLC Updates: 2460 P. Chimento Category: Standards Track Johns Hopkins University Applied ISSN: 2070-1721 Physics Laboratory M. Westerlund Ericsson April 2013 IPv6 and UDP Checksums for Tunneled Packets
AbstractThis document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried. Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6935.
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. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Analysis of Corruption in Tunnel Context . . . . . . . . . 5 4.2. Limitation to Tunnel Protocols . . . . . . . . . . . . . . 7 4.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 8 5. The Zero UDP Checksum Update . . . . . . . . . . . . . . . . . 9 6. Additional Observations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
RFC2460] for cases where a tunnel protocol uses UDP with IPv6 to tunnel packets. With the rapid growth of the Internet, tunnel protocols have become increasingly important to enable the deployment of new protocols. Tunnel protocols can be deployed rapidly, while the time to upgrade and deploy a new protocol on a critical mass of routers, middleboxes, and hosts on the global Internet is now measured in decades. At the same time, the increasing use of firewalls and other security-related middleboxes means that truly new tunnel protocols, with new protocol numbers, are also unlikely to be deployable in a reasonable time frame. The result is an increasing interest in and use of UDP-based tunnel protocols. In such protocols, there is an encapsulated "inner" packet, and the "outer" packet carrying the tunneled inner packet is a UDP packet, which can pass through firewalls and other middleboxes that perform the filtering that is a fact of life on the current Internet. Tunnel endpoints may be routers or middleboxes aggregating traffic from a number of tunnel users. Therefore, the computation of an additional checksum on the outer UDP packet may be seen as an unwarranted burden on nodes that implement a tunnel protocol, especially if the inner packets are already protected by a checksum. IPv4 has a checksum over the IP packet header, and the checksum on the outer UDP packet may be set to zero. However, IPv6 has no checksum in the IP header, and RFC 2460 [RFC2460] explicitly states that IPv6 receivers MUST discard UDP packets with a zero checksum. So, while sending a UDP datagram with a zero checksum is permitted in IPv4 packets, it is explicitly forbidden in IPv6 packets. To improve support for IPv6 UDP tunnels, this document updates RFC 2460 to allow endpoints to use a zero UDP checksum under constrained situations (primarily for IPv6 tunnel transports that carry checksum-protected packets), following the applicability statements and constraints in [RFC6936]. When reading this document, the advice in "Unicast UDP Usage Guidelines for Application Designers" [RFC5405] is applicable. It discusses both UDP tunnels (Section 3.1.3) and the usage of checksums (Section 3.4). While the origin of this specification is the problem raised by the draft titled "Automatic Multicast Tunnels", also known as "AMT" [AMT], we expect it to have wide applicability. Since the first draft of this RFC was written, the need for an efficient UDP tunneling mechanism has increased. Other IETF Working Groups, notably LISP [RFC6830] and Softwires [RFC5619], have expressed a need
to update the UDP checksum processing in RFC 2460. We therefore expect this update to be applicable in the future to other tunnel protocols specified by these and other IETF Working Groups. RFC2119]. RFC6936] describes issues related to allowing UDP over IPv6 to have a valid zero UDP checksum and is the starting point for this discussion. Sections 4 and 5 of [RFC6936], respectively, identify node implementation and usage requirements for datagrams sent and received with a zero UDP checksum. These sections introduce constraints on the usage of a zero checksum for UDP over IPv6. The remainder of this section analyzes the use of general tunnels and explains the motivations for why tunnel protocols are being permitted to use the method described in this update. It also discusses issues with middleboxes.
* If a corrupted datagram matches a 5-tuple and node has not enabled the zero checksum for this port, the datagram will be discarded. When only the source information is corrupted, the datagram could arrive at the intended applications or protocol, which will process the datagram and try to match it against an existing tunnel context. The likelihood that a corrupted packet enters a valid context is reduced when the protocol restricts processing to only the source addresses with established contexts. When both source and destination fields are corrupted, this also decreases the likelihood of matching a context. However, the exception is when errors replace one packet header with another, so both packets could be tunneled, and therefore the corrupted packet could match a previously defined context. o Receivers should attempt to detect corruption of source-fragmented encapsulating packets. A tunnel protocol may reassemble fragments associated with the wrong context at the right tunnel endpoint, it may reassemble fragments associated with a context at the wrong tunnel endpoint, or corrupted fragments may be reassembled at the right context at the right tunnel endpoint. In each of these cases, the IPv6 length of the encapsulating header may be checked (although [RFC6936] points out the weakness in this check). In addition, if the encapsulated packet is protected by a transport (or other) checksum, these errors can be detected (with some probability). o Compared to other applications, tunnel protocols using UDP have some advantages that reduce the risk for a corrupted tunnel packet reaching a destination that will receive it. These advantages result from processing by the network of the inner (tunneled) packet after it is forwarded from the tunnel egress using a wrong context: * A tunneled packet may be forwarded to the wrong address domain, for example, to a private address domain where the inner packet's address is not routable, or it may fail a source address check, such as Unicast Reverse Path Forwarding [RFC2827], resulting in the packet being dropped. * The destination address of a tunneled packet may not be reachable at all from the delivered domain. An example is an Ethernet frame where the destination MAC address is not present on the LAN segment that was reached.
* The type of the tunneled packet may prevent delivery. For example, an attempt to interpret an IP packet payload as an Ethernet frame would likely to result in the packet being dropped as invalid. * The tunneled packet checksum or integrity mechanism may detect corruption of the inner packet caused at the same time as corruption to the outer packet header. The resulting packet would likely be dropped as invalid. Each of these checks significantly reduces the likelihood that a corrupted inner tunneled packet is finally delivered to a protocol listener that can be affected by the packet. While the methods do not guarantee correctness, they can reduce the risks of relaxing the UDP checksum requirement for a tunnel application using IPv6.
protocol state. One common effect is that the inner packet flow will see only a corruption and a misdelivery of the outer packet as a lost packet. o Some non-tunnel protocols operate with general servers that do not know the source from which they will receive a packet. In such applications, a zero UDP checksum is unsuitable, because it is necessary to provide the first level of verification that the packet was intended for the receiving server. A verification prevents the server from processing the datagram payload; without this, the server may spend significant resources processing the packet, including sending replies or error messages. Tunnel protocols that encapsulate IP will generally be safe for deployment, because all IPv4 and IPv6 packets include at least one checksum at either the network or transport layer. The network delivery of the inner packet will then further reduce the effects of corruption. Tunnel protocols carrying non-IP packets may offer equivalent protection when the non-IP networks reduce the risk of misdelivery to applications. However, further analysis is necessary to understand the implications of misdelivery of corrupted packets for each non-IP protocol. The analysis above suggests that non- tunnel protocols can be expected to have significantly more cases where a zero checksum would result in misdelivery or negative side effects. One unfortunate side effect of increased use of a zero checksum is that it also increases the likelihood of acceptance when a datagram with a zero UDP checksum is misdelivered. This requires all tunnel protocols using this method to be designed to be robust in the face of misdelivery. RFC6936] specifies requirements for middleboxes and tunnels that need to traverse middleboxes. Tunnel protocols intending to use a zero UDP checksum need to ensure that they have defined a method for handling cases when a middlebox prevents the path between the tunnel ingress and egress from supporting transmission of datagrams with a zero UDP checksum. This is especially important as middleboxes that conform to RFC 2460 are likely to discard datagrams with a zero UDP checksum.
RFC6936]. The following text in [RFC2460], Section 8.1, fourth bullet should be deleted: Unlike IPv4, when UDP packets are originated by an IPv6 node, the UDP checksum is not optional. That is, whenever originating a UDP packet, an IPv6 node must compute a UDP checksum over the packet and the pseudo-header, and, if that computation yields a result of zero, it must be changed to hex FFFF for placement in the UDP header. IPv6 receivers must discard UDP packets containing a zero checksum, and should log the error. This text should be replaced by: An IPv6 node associates a mode with each used UDP port (for sending and/or receiving packets). Whenever originating a UDP packet for a port in the default mode, an IPv6 node MUST compute a UDP checksum over the packet and the pseudo-header, and, if that computation yields a result of zero, the checksum MUST be changed to hex FFFF for placement in the UDP header, as specified in [RFC2460]. IPv6 receivers MUST by default discard UDP packets containing a zero checksum and SHOULD log the error. As an alternative, certain protocols that use UDP as a tunnel encapsulation MAY enable zero-checksum mode for a specific port (or set of ports) for sending and/or receiving. Any node implementing zero-checksum mode MUST follow the node requirements specified in Section 4 of "Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936]. Any protocol that enables zero-checksum mode for a specific port or ports MUST follow the usage requirements specified in Section 5 of "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936]. Middleboxes supporting IPv6 MUST follow requirements 9, 10, and 11 of the usage requirements specified in Section 5 of "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936].
RFC6830], may prefer to use UDP tunnels to traverse an end-to-end path successfully and avoid having their packets dropped by middleboxes. If middleboxes were updated to support UDP-Lite [RFC3828], UDP-Lite would provide better protection than offered by this update. UDP-Lite may be suited to a variety of applications and would be expected to be preferred over this method for many tunnel protocols. o Another issue is that the UDP checksum is overloaded with the task of protecting the IPv6 header for UDP flows (as is the TCP checksum for TCP flows). Protocols that do not use a pseudo- header approach to computing a checksum or CRC have essentially no protection from misdelivered packets.
an acceptable rate for transmission. This processing overhead 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 a 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 router's slow path. Therefore, protection mechanisms should be employed when this threat exists. Protection may include source- address filtering to prevent an attacker from injecting traffic, as well as throttling the amount of non-zero checksum traffic. The latter may impact the functioning of the tunnel protocol. RFC6936]. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, April 2013. [AMT] Bumgardner, G., "Automatic Multicast Tunneling", Work in Progress, June 2012. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008. [RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent, "Softwire Security Analysis and Requirements", RFC 5619, August 2009. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.