--- 1/draft-ietf-6man-udpchecksums-01.txt 2012-03-12 23:13:59.567006008 +0100 +++ 2/draft-ietf-6man-udpchecksums-02.txt 2012-03-12 23:13:59.587004162 +0100 @@ -1,20 +1,20 @@ Network Working Group M. Eubanks Internet-Draft AmericaFree.TV LLC Intended status: Standards Track P. Chimento -Expires: May 3, 2012 Johns Hopkins University Applied +Expires: September 13, 2012 Johns Hopkins University Applied Physics Laboratory - October 31, 2011 + March 12, 2012 UDP Checksums for Tunneled Packets - draft-ietf-6man-udpchecksums-01 + draft-ietf-6man-udpchecksums-02 Abstract This document provides an update of RFC 2460[RFC2460] in order to improve the performance of IPv6 in an increasingly important use case, the use of tunneling to carry new transport protocols. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for suitable tunneling protocol where header information is protected on the "inner" packet being carried. This relaxation removes the overhead associated with the computation of UDP checksums @@ -39,25 +39,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 May 3, 2012. + This Internet-Draft will expire on September 13, 2012. Copyright Notice - Copyright (c) 2011 IETF Trust and the persons identified as the + Copyright (c) 2012 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 @@ -112,23 +112,23 @@ checksum is permitted in IPv4 packets, it is explicitly forbidden in IPv6 packets. In order to meet the needs of the deployers of IPv6 UDP tunnels, this document modifies RFC 2460 to allow for the ignoring of UDP checksums under constrained situations (IPv6 tunneling where the inner packet exists and has a checksum), based on the considerations set forth in [I-D.ietf-6man-udpzero]. While the origin of this I-D is the problem raised by the draft titled "Automatic IP Multicast Without Explicit Tunnels", also known as "AMT," [I-D.ietf-mboned-auto-multicast] we expect it to have wide - applicability, immediately to LISP [I-D.ietf-lisp], and also to other - tunneling protocols to come out of Softwires and other IETF Working - Groups. + applicability, immediately to AMT and LISP [I-D.ietf-lisp], and in + the future to other tunneling protocols to come out of Softwires and + other IETF Working Groups. Since the first version of this document, the need for an efficient, lightweight UDP tunneling mechanism has increased. Indeed, other workgroups, notably LISP [I-D.ietf-lisp] and Softwires [RFC5619] have also expressed a need to have exceptions to the RFC 2460 prohibition. Other users of UDP as a tunneling protocol, for example, L2TP and Softwires may benefit from a relaxation of the RFC 2460 restriction. The third version of this document benefited from a close read by @@ -163,28 +163,28 @@ [I-D.ietf-6man-udpzero] describes the issues related to allowing UDP over IPv6 to have a valid checksum of zero and is not repeated here. In Section 5.1 of [I-D.ietf-6man-udpzero], the authors propose nine (9) constraints on the usage of a zero checksum for UDP over IPv6. We agree with the restrictions proposed, and in fact proposed some of those restrictions ourselves in the previous version of the current draft. These restrictions are incorporated into the proposed changes below. - As has been pointed out in [I-D.ietf-6man-udpzero] and in many - mailing lists, there is still the possibility of deep-inspection - firewall devices or other middleboxes actually checking the UDP - checksum field of the outer packet and discarding the tunneling - packets. This is would be an issue also for legacy systems which - have not implemented the change in the IPv6 specification. So in any - case, there may be packet loss of lightweight tunneling packets - because of mixed new-rule and old-rule nodes. + As has been pointed out in [I-D.ietf-6man-udpzero] and in various + mailing list discussions, there is still the possibility of deep- + inspection firewall devices or other middleboxes actually checking + the UDP checksum field of the outer packet and thereby discarding the + tunneling packets. This is would be an issue also for legacy systems + which have not implemented the change in the IPv6 specification. So + in any case, there may be packet loss of lightweight tunneling + packets because of mixed new-rule and old-rule nodes. As an example, we discuss how can errors be detected and handled in a lightweight UDP tunneling protocol when the checksum protection is disabled. Note that other (non-tunneling) protocols may have different approaches. We suggest that the following could be an approach to this problem: o Context (i.e. tunneling state) should be established via application PDUs that are carried in checksummed UDP packets. That is, any control packets flowing between the tunnel endpoints @@ -372,32 +372,32 @@ being developed in the IETF requires a definitive policy. The authors would like to make the following observations: o An empirically-based analysis of the probabilities of packet corruptions (with or without checksums) has not (to our knowledge) been conducted since about 2000. It is now 2011. We strongly suggest that an empirical study is in order, along with an extensive analysis of IPv6 header corruption probabilities. o A key cause of this issue generally is the lack of protocol - support in middleboxes. Specifically, new protocols, such as - LISP, are being forced to use UDP tunnels just to traverse an end- - to-end path successfully and avoid having their packets dropped by - middleboxes. If this were not the case, the use of UDP-lite might - become more viable for some (but not necessarily all) lightweight - tunneling protocols. + support in middleboxes. Specifically, new protocols, such as LISP + [I-D.ietf-lisp], are being forced to use UDP tunnels just to + traverse an end-to-end path successfully and avoid having their + packets dropped by middleboxes. If this were not the case, the + use of UDP-lite [RFC3828] might become more viable for some (but + not necessarily all) lightweight tunneling protocols. o Another cause of this issue is that the UDP checksum is overloaded with the task of protecting the IPv6 header for UDP flows (as it 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. + essentially no protection from mis-delivered 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 @@ -417,51 +417,47 @@ We would like to thank Brian Haberman, Magnus Westerlund and Gorry Fairhurst for discussions and reviews. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [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. [RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent, "Softwire Security Analysis and Requirements", RFC 5619, August 2009. 10.2. Informative References [I-D.ietf-6man-udpzero] Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum - Considerations", draft-ietf-6man-udpzero-04 (work in - progress), October 2011. + Considerations", draft-ietf-6man-udpzero-05 (work in + progress), December 2011. [I-D.ietf-lisp] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", - draft-ietf-lisp-15 (work in progress), July 2011. + draft-ietf-lisp-22 (work in progress), February 2012. [I-D.ietf-mboned-auto-multicast] - Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. - Pusateri, "Automatic IP Multicast Without Explicit Tunnels - (AMT)", draft-ietf-mboned-auto-multicast-11 (work in - progress), July 2011. + Bumgardner, G. and T. Morin, "Automatic Multicast + Tunneling", draft-ietf-mboned-auto-multicast-12 (work in + progress), February 2012. Authors' Addresses Marshall Eubanks AmericaFree.TV LLC P.O. Box 141 Clifton, Virginia 20124 USA Phone: +1-703-501-4376