--- 1/draft-ietf-6man-udpchecksums-07.txt 2013-02-21 15:23:21.463791747 +0100 +++ 2/draft-ietf-6man-udpchecksums-08.txt 2013-02-21 15:23:21.487791036 +0100 @@ -1,22 +1,22 @@ Network Working Group M. Eubanks Internet-Draft AmericaFree.TV LLC Updates: 2460 (if approved) P. Chimento Intended status: Standards Track Johns Hopkins University Applied -Expires: July 21, 2013 Physics Laboratory +Expires: August 25, 2013 Physics Laboratory M. Westerlund Ericsson - January 17, 2013 + February 21, 2013 IPv6 and UDP Checksums for Tunneled Packets - draft-ietf-6man-udpchecksums-07 + draft-ietf-6man-udpchecksums-08 Abstract This document provides an update of the Internet Protocol version 6 (IPv6) specification (RFC2460) to improve the performance in the use case where a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for any suitable tunnel protocol where header information is protected on the "inner" packet being carried. This relaxation removes the overhead associated with the computation of @@ -34,21 +34,21 @@ 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 21, 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 @@ -62,27 +62,27 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Some 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-Checksum Update . . . . . . . . . . . . . . . . . . . 8 - 6. Additional Observations . . . . . . . . . . . . . . . . . . . 9 + 6. Additional Observations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction This work constitutes an update of the Internet Protocol Version 6 (IPv6) Specification [RFC2460], in the use case 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 critical @@ -118,24 +118,24 @@ "Unicast UDP Usage Guidelines for Application Designers" [RFC5405] should be consulted when reading this specification. 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" [I-D.ietf-mboned-auto-multicast] we expect it to have wide applicability. Since the first version of this document, the need for an efficient UDP tunneling mechanism has increased. Other IETF - Working Groups, notably LISP [I-D.ietf-lisp] 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 + 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. 2. Some Terminology This document discusses only IPv6, since this problem does not exist for IPv4. Therefore all reference to 'IP' should be understood as a reference to IPv6. The document uses the terms "tunneling" and "tunneled" as adjectives when describing packets. When we refer to 'tunneling packets' we @@ -372,35 +372,37 @@ "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 active UDP port. + 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, - it MUST be changed to hex FFFF for placement in the UDP header. - IPv6 receivers MUST by default discard UDP packets containing a - zero checksum, and SHOULD log the error. + it 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 the zero-checksum mode for a specific - port (or set of ports). Any node implementing the 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" [I-D.ietf-6man-udpzero]. + port (or set of ports) for sending and/or receiving. Any node + implementing the 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" + [I-D.ietf-6man-udpzero]. Any protocol that enables the 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" [I-D.ietf-6man-udpzero]. 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" [I-D.ietf-6man-udpzero]. @@ -409,84 +411,103 @@ This update was motivated by the existence of a number of protocols being developed in the IETF that are expected to benefit from the change. The following observations are made: o An empirically-based analysis of the probabilities of packet corruption (with or without checksums) has not (to our knowledge) been conducted since about 2000. At the time of publication, it is now 2012. We strongly suggest a new empirical study, along with an extensive analysis of the corruption probabilities of the - IPv6 header. + IPv6 header. This can potentially allow revising the + recommendations in this document. o A key motivation for the increase in use of UDP in tunneling is a lack of protocol support in middleboxes. Specifically, new - protocols, such as LISP [I-D.ietf-lisp], 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. This may be suited - to a variety of applications and would be expected to be preferred - over this method for many tunnel protocols. + protocols, such as LISP [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. This 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. 7. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 8. Security Considerations Less work is required to generate an attack using a zero UDP checksum than one using a standard full UDP checksum. However, this does not lead to significant new vulnerabilities because checksums are not a security measure and can be easily generated by any attacker. - Properly configured tunnels should check the validity of the inner - packet and perform security checks. + + In general any user of zero UDP checksums should apply the checks and + context verification that are possible to minimize the risk of + unintended traffic to reach a particular context. This will however + not protect against an intended attack that create packet with the + correct information. Source address validation can help prevent + injection of traffic into contexts by an attacker. + + 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. 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. 9. Acknowledgements - We would like to thank Brian Haberman, Dan Wing, Joel Halpern and the - IESG of 2012 for discussions and reviews. Gorry Fairhurst has been - very diligent in reviewing and help ensuring alignment between this - document and [I-D.ietf-6man-udpzero]. + We would like to thank Brian Haberman, Dan Wing, Joel Halpern, David + Waltermire, J.W. Atwood, Peter Yee, Joe Touch and the IESG of 2012 + for discussions and reviews. Gorry Fairhurst has been very diligent + in reviewing and help ensuring alignment between this document and + [I-D.ietf-6man-udpzero]. 10. References 10.1. Normative References [I-D.ietf-6man-udpzero] Fairhurst, G. and M. Westerlund, "Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums", - draft-ietf-6man-udpzero-08 (work in progress), - December 2012. + draft-ietf-6man-udpzero-10 (work in progress), + January 2013. [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. 10.2. Informative References - [I-D.ietf-lisp] - Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, - "Locator/ID Separation Protocol (LISP)", - draft-ietf-lisp-24 (work in progress), November 2012. - [I-D.ietf-mboned-auto-multicast] Bumgardner, G., "Automatic Multicast Tunneling", draft-ietf-mboned-auto-multicast-14 (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 @@ -494,20 +515,24 @@ (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. + Authors' Addresses Marshall Eubanks AmericaFree.TV LLC P.O. Box 141 Clifton, Virginia 20124 USA Phone: +1-703-501-4376 Fax: