idnits 2.17.1 draft-eubanks-chimento-6man-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The argument made by the draft authors is that since multicast packets already have a UDP header with a checksum, there is no additional benefit and indeed some cost to nodes to both compute and check the UDP checksum of the outer (encapsulating) header. However, Consequently, IPv6 should make an exception to the rule that the UDP checksum MUST not be 0, and allow tunneling protocols to set the checksum field of the outer header only to 0 and skip both the sender and receiver computation. -- The document date (February 23, 2009) is 5541 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2401' is defined on line 230, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 233, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Eubanks 3 Internet-Draft Iformata Communications 4 Intended status: Standards Track P. Chimento 5 Expires: August 27, 2009 Johns Hopkins University Applied 6 Physics Laboratory 7 February 23, 2009 9 UDP Checksums for Tunneled Packets 10 draft-eubanks-chimento-6man-00 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 27, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 We address the problem of computing the UDP checksum on tunneling 50 IPv6 packets when using lightweight tunneling protocols. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Some Terminology . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . . 3 63 1.3. Alternate Solutions . . . . . . . . . . . . . . . . . . . . 3 64 1.4. Possible Pitfalls of a change . . . . . . . . . . . . . . . 4 65 1.5. Recommended Solution . . . . . . . . . . . . . . . . . . . 5 66 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. Normative References . . . . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 The origin of this I-D is the problem raised by the draft titled 75 "Automatic IP Multicast Without Explicit Tunnels", also known as 76 "AMT". This draft uses UDP as the layer protocol in tunneling 77 packets; that is, the outer packet carrying a tunneled (inner) 78 packet. The draft specifies that for packets carrying tunneled 79 multicast data only, the UDP checksum in the UDP header of the outer 80 packet SHOULD be 0 (See draft-ietf-mboned-auto-multicast-09, Section 81 6.6). However RFC 2460 (IPv6) explicitly states that IPv6 receivers 82 MUST discard UDP packets with a 0 checksum. So, while sending a UDP 83 packet with a 0 checksum is permitted in IPv4 packets, it is 84 explicitly forbidden in IPv6 packets. 86 The computation of an additional checksum, when the inner packet(s) 87 are already adequately protected, is seen to be an unwarranted burden 88 on nodes implementing lightweight tunneling protocols. 90 1.1. Some Terminology 92 For the remainder of this draft, we discuss only IPv6, since this 93 problem does not exist for IPv4. So any reference to 'IP' should be 94 understood as a reference to IPv6. 96 Although we will try to avoid them when possible, we may use the 97 terms "tunneling" and "tunneled" as adjectives when describing 98 packets. When we refer to 'tunneling packets' we refer to the outer 99 packet header that provides the tunneling function. When we refer to 100 'tunneled packets' we refer to the inner packet, i.e. the packet 101 being carried in the tunnel. 103 1.2. Problem Statement 105 The argument made by the draft authors is that since multicast 106 packets already have a UDP header with a checksum, there is no 107 additional benefit and indeed some cost to nodes to both compute and 108 check the UDP checksum of the outer (encapsulating) header. However, 109 Consequently, IPv6 should make an exception to the rule that the UDP 110 checksum MUST not be 0, and allow tunneling protocols to set the 111 checksum field of the outer header only to 0 and skip both the sender 112 and receiver computation. 114 1.3. Alternate Solutions 116 1. UDP-lite: Some suggestions on the mailing list have been to use 117 UDP-lite (RFC 3828) [RFC3828]. This solution minimizes 118 computation. For example, if a tunneling protocol were to use 119 UDP-lite with a checksum coverage field of 8 to construct the 120 outer (tunneling) packet, the only variable quantity for a given 121 tunnel is the packet length of the inner (tunneled) packet, since 122 the IPv6 pseudo-header is otherwise fixed. This is a constant 123 value then added to the inner packet length (which should be 124 known when the outer packet is constructed). This is simply an 125 add and store, and a computation of the pseudo-header checksum 126 when the tunnel is created. The possible objections to this 127 approach are twofold: First, it still involves computation which 128 some view as unnecessary. Second, NAT traversal is a problem for 129 UDP-lite and may cause packet loss. 131 2. No exception for lightweight tunneling: Retain the IPv6 132 specification as it stands and do not allow a UDP checksum equal 133 to 0 in an outer IPv6 tunneling packet. 135 3. Exception for lightweight tunneling: Amend IPv6 to allow a 0 136 value in the UDP checksum field for leightweight tunneling 137 protocols which allows them to bypass any checksum computation in 138 the outer header if the inner packet is protected. Rules for 139 usage in this case must be developed. 141 4. Another possibilty is to allow an exception for the AMT protocol 142 only. This may seem undesirable, but it would restrict the 143 implementation of a zero checksum UDP header over IPv6 only to 144 the AMT endpoints. Any misdelivered packets (i.e. arriving at a 145 non-AMT endpoint) would simply be discarded. 147 1.4. Possible Pitfalls of a change 149 One potential problem with the approach which allows an exception to 150 the IPv6 UDP checksum rule is that in general, tunneling (outer) IPv6 151 packets could be encapsulating either IPv6 packets or IPv4 packets. 152 If the inner (tunneled) packet is an IPv4 packet with a 0 UDP 153 checksum, then the neither the inner nor the outer packet will 154 provide any checksum protection. This would likewise be the case if 155 the inner packet were an IPv6 packet produced by another (future) 156 protocol which uses an exception to the IPv6 rule. 158 Others on the mailing list have pointed out other issues with 159 changing the IPv6 specification to allow a checksum of 0 on the outer 160 packet header. In particular, Matt Mathis points out that some 161 tunneling devices ignore the DF bit and fragment silently. This 162 would allow two fragmented UDP packets to be spliced together and be 163 decapsulated and forwarded by a tunnel endpoint. 165 One notes also that there is no IPv6 header checksum. 167 There is also the possibility of deep-inspection firewall devices or 168 other middleboxes actually checking the UDP checksum field of the 169 outer packet and discarding the tunneling packets. This is would be 170 an issue also for legacy systems which have not implemented the 171 change in the IPv6 specification. So in any case, there may be 172 packet loss of lightweight tunneling packets because of mixed new- 173 rule and old-rule nodes. 175 1.5. Recommended Solution 177 There seems to be some general opinion that a UDP checksum of 0 could 178 be allowed on the outer encapsulating packet of a lightweight 179 tunneling protocol. This would imply that UDP endpoints handling 180 that protocol must change their behavior and not discard UDP packets 181 received with a 0 checksum on the outer packet. 183 Magnus Westerlund proposed some restrictions on using a UDP header 184 checksum of 0. These are: 186 1. There must be some way to verify the integrity of the inner 187 (tunneled) packet. 189 2. The tunneling protocol and implementation must not use 190 fragmentation of the inner packets being carried. 192 We would suggest the following elaborations of the above 193 restrictions, if a change in the IPv6 specification moves forward: 195 o An inner IPv4 packet with a UDP checksum equal to 0 must not be 196 tunneled. 198 o Non-IP inner packets must have a CRC or other mechanism for 199 checking packet integrity. 201 o Other tunneling protcocols that use the UDP checksum equal to 0 202 MUST NOT be tunneled themselves, even if more deeply encapsulated 203 packets have checksums or other integrity checking mechanisms. 205 o We would recommend that general protocol stack implementations do 206 NOT implement this change. The exception should remain restricted 207 to devices serving as endpoints of the lightweight tunneling 208 protocol adopting the change. 210 In addition, we would recommend that a security analysis be done in 211 order to assess whether any new vulnerabilities are introduced by 212 such a change. 214 2. IANA Considerations 216 This document makes no request of IANA. 218 Note to RFC Editor: this section may be removed on publication as an 219 RFC. 221 3. Security Considerations 223 4. Acknowledgements 225 5. Normative References 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 231 Internet Protocol", RFC 2401, November 1998. 233 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 234 (IPv6) Specification", RFC 2460, December 1998. 236 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 237 G. Fairhurst, "The Lightweight User Datagram Protocol 238 (UDP-Lite)", RFC 3828, July 2004. 240 Authors' Addresses 242 Marshall Eubanks 243 Iformata Communications 245 Phone: 246 Fax: 247 Email: tme@multicasttech.com 248 URI: 250 P.F. Chimento 251 Johns Hopkins University Applied Physics Laboratory 252 11100 Johns Hopkins Road 253 Laurel, MD 20723 254 USA 256 Phone: +1-443-778-1743 257 Fax: 258 Email: Philip.Chimento@jhuapl.edu 259 URI: