idnits 2.17.1 draft-eubanks-chimento-6man-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 66 lines 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 in the case of AMT 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. 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 (October 24, 2010) is 4926 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 400, but no explicit reference was found in the text == Unused Reference: 'RFC3828' is defined on line 406, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-6man-udpzero-02 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-09 ** Downref: Normative reference to an Experimental draft: draft-ietf-lisp (ref. 'I-D.ietf-lisp') ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 3 errors (**), 0 flaws (~~), 7 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: April 27, 2011 Johns Hopkins University Applied 6 Physics Laboratory 7 October 24, 2010 9 UDP Checksums for Tunneled Packets 10 draft-eubanks-chimento-6man-01 12 Abstract 14 We address the problem of computing the UDP checksum on tunneling 15 IPv6 packets when using lightweight tunneling protocols. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 27, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Some Terminology . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 60 1.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.4. Recommended Solution . . . . . . . . . . . . . . . . . . . 6 62 1.5. Additional Observations . . . . . . . . . . . . . . . . . 8 63 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 66 5. Normative References . . . . . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 68 Intellectual Property and Copyright Statements . . . . . . . . . . 11 70 1. Introduction 72 The origin of this I-D is the problem raised by the draft titled 73 "Automatic IP Multicast Without Explicit Tunnels", also known as 74 "AMT". See draft-ietf-mboned-auto-multicast-09, Section 6.6. That 75 draft used UDP as the transport layer protocol for tunneling packets; 76 that is, the outer packet carrying a tunneled (inner) packet is a UDP 77 packet. The draft specifies that for packets carrying tunneled 78 multicast data only, the UDP checksum in the UDP header of the outer 79 packet SHOULD be 0. 81 However RFC 2460 [RFC2460] explicitly states that IPv6 receivers MUST 82 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. The reason that this 85 prohibition exists is that there is no header checksum in the IPv6 86 header. The computation of an additional checksum, when the inner 87 packet(s) are already adequately protected, is seen to be an 88 unwarranted burden on nodes implementing lightweight tunneling 89 protocols. However, there are issues with a UDP checksum of zero in 90 IPv6 packets; these issues are described in detail in 91 [I-D.ietf-6man-udpzero] 93 Since the first version of this draft, the need for an efficient, 94 lightweight UDP tunneling mechanism has increased. Indeed, other 95 workgroups, notably LISP [I-D.ietf-lisp] and Softwires [RFC5619] have 96 also expressed a need to have exceptions to the RFC 2460 prohibition. 97 More recently, a discussion on the DCCP mailing list covered the UDP 98 over IPv6 checksum issues. Other users of UDP as a tunneling 99 protocol, for example, L2TP and Softwires may benefit from a 100 relaxation of the RFC 2460 restriction. 102 1.1. Some Terminology 104 For the remainder of this draft, we discuss only IPv6, since this 105 problem does not exist for IPv4. So any reference to 'IP' should be 106 understood as a reference to IPv6. 108 Although we will try to avoid them when possible, we may use the 109 terms "tunneling" and "tunneled" as adjectives when describing 110 packets. When we refer to 'tunneling packets' we refer to the outer 111 packet header that provides the tunneling function. When we refer to 112 'tunneled packets' we refer to the inner packet, i.e. the packet 113 being carried in the tunnel. 115 1.2. Problem Statement 117 The argument made by the draft authors is that since in the case of 118 AMT multicast packets already have a UDP header with a checksum, 119 there is no additional benefit and indeed some cost to nodes to both 120 compute and check the UDP checksum of the outer (encapsulating) 121 header. Consequently, IPv6 should make an exception to the rule that 122 the UDP checksum MUST not be 0, and allow tunneling protocols to set 123 the checksum field of the outer header only to 0 and skip both the 124 sender and receiver computation. 126 1.3. Discussion 128 The draft [I-D.ietf-6man-udpzero] does an excellent job of discussing 129 all the issues related to allowing UDP over IPv6 to have a valid 130 checksum of zero. We will not repeat that work here. 132 In Section 5.1 of [I-D.ietf-6man-udpzero], the authors propose nine 133 (9) constraints on the usage of a zero checksum for UDP over IPv6. 134 We agree with the restrictions proposed, and in fact proposed some of 135 those restrictions ourselves in the previous version of the current 136 draft. These restrictions are incorporated into the proposed changes 137 below. 139 As has been pointed out in [I-D.ietf-6man-udpzero] and in many 140 mailing lists, there is still the possibility of deep-inspection 141 firewall devices or other middleboxes actually checking the UDP 142 checksum field of the outer packet and discarding the tunneling 143 packets. This is would be an issue also for legacy systems which 144 have not implemented the change in the IPv6 specification. So in any 145 case, there may be packet loss of lightweight tunneling packets 146 because of mixed new-rule and old-rule nodes. 148 As an example, we discuss how can errors be detected and handled in a 149 lightweight UDP tunneling protocol when the checksum protection is 150 disabled. Note that other (non-tunneling) protocols may have 151 different approaches. We suggest that the following could be an 152 approach to this problem: 154 o Context (i.e. tunneling state) should be established via 155 application PDUs that are carried in checksummed UDP packets. 156 That is, any control packets flowing between the tunnel endpoints 157 should be protected by UDP checksums. The control packets can 158 also contain any negotiation that is necessary to set up the 159 endpoint/adapters to accept UDP packets with a zero checksum. 161 o Only UDP packets containing tunneled packets should have a UDP 162 checksum equal to zero. 164 o UDP keep-alive packets with checksum zero can be sent to validate 165 paths, given that paths between tunnel endpoints can change and so 166 middleboxes in the path may vary during the life of the 167 association. Paths with middleboxes that are intolerant of a UDP 168 checksum of zero will drop the keep-alives and the endpoints will 169 discover that. Note that this need only be done per tunnel 170 endpoint pair, not per tunnel context. 172 o Corruption of the encapsulating IPv6 source address, destination 173 address and/or the UDP source port, destination port fields : If 174 the 9 restrictions in [I-D.ietf-6man-udpzero] are followed, the 175 inner packets (tunneled packets) should be protected and run the 176 usual (presumably small) risk of having undetected corruption(s). 177 If lightweight tunneling protocol contexts contain (at a minumum) 178 source and destination IP addresses and source and destination 179 ports, there are 16 possible corruption outcomes. We note that 180 not only are these outcomes not equally likely, most require 181 multiple bit errors with errored bits in separate fields. The 182 possible corruption outcomes fall out this way: 184 * Half of the 16 possible corruption combinations have a 185 corrupted destination address. If the incorrect destination is 186 reached and the node doesn't have an application for the 187 destination port, the packet will be dropped. If the 188 application at the incorrect destination is the same 189 lightweight tunneling protocol and if it has a matching context 190 (we assume a very small probability event) the inner packet 191 will be decapsulated and forwarded. If it is some other 192 application, with very high probability, the application will 193 not recognize the contents of the packet. 195 * Half of the 8 possible corruption combinations with a correct 196 destination address have a corrupted source address. If the 197 tunnel contexts contain all elements of the address-port 198 4-tuple, then the liklihood is that this corruption will be 199 detected. 201 * Of the remaining 4 possibilities, with valid source and 202 destination IPv6 addresses, 1 has all 4 fields valid, the other 203 three have one or both ports corrupted. Again, if the 204 tunneling endpoint context contains sufficient information, 205 these error should be detected with high probability. 207 o Corruption of source-fragmented encapsulating packets: In this 208 case, a tunneling protocol may reassemble fragments associated 209 with the wrong context at the right tunnel endpoint, or it may 210 reassemble fragments associated with a context at the wrong tunnel 211 endpoint, or corrupted fragments may be reassembled at the right 212 context at the right tunnel endpoint. In each of these cases, the 213 IPv6 length of the encapsulating header may be checked (though 214 [I-D.ietf-6man-udpzero] points out the weakness in this check). 215 In addition, if the encapsulated packet is protected by a 216 transport (or other) checksum, these errors can be detected (with 217 some probability). 219 While this is not a perfect solution, it can reduce the risks of 220 relaxing the UDP checksum requirement for IPv6. 222 1.4. Recommended Solution 224 There is a need that a UDP checksum of zero could be allowed on the 225 outer encapsulating packet of a lightweight tunneling protocol. This 226 would imply that UDP endpoints handling that protocol must change 227 their behavior and not discard UDP packets received with a 0 checksum 228 on the outer packet. We also recommend that the constraints in 229 Section 5.1 of [I-D.ietf-6man-udpzero] be adopted. 231 Specifically, this draft proposes that the text in [RFC2460] Section 232 8.1, 4th bullet be amended. We refer to the following text: 234 "Unlike IPv4, when UDP packets are originated by an IPv6 node, the 235 UDP checksum is not optional. That is, whenever originating a UDP 236 packet, an IPv6 node must compute a UDP checksum over the packet and 237 the pseudo-header, and, if that computation yields a result of zero, 238 it must be changed to hex FFFF for placement in the UDP header. IPv6 239 receivers must discard UDP packets containing a zero checksum, and 240 should log the error." 242 This item should be taken out of the bullet list and should be 243 modified as follows: 245 Whenever originating a UDP packet, an IPv6 node SHOULD compute a 246 UDP checksum over the packet and the pseudo-header, and, if that 247 computation yields a result of zero, it must be changed to hex 248 FFFF for placement in the UDP header. IPv6 receivers SHOULD 249 discard UDP packets containing a zero checksum, and SHOULD log the 250 error. However, some protocols, such as lightweight tunneling 251 protocols that use UDP as a tunnel encapsulation, MAY omit 252 computing the UDP checksum of the encapsulating UDP header and set 253 it to zero, subject to the following constraints (from 254 [I-D.ietf-6man-udpzero]). In cases, where the encapsulating 255 protocol uses a zero checksum for UDP, the receiver of packets in 256 the allowed port range MUST NOT discard packets with a UDP 257 checksum of zero. Note that these constraints apply only to 258 encapsulating protocols that omit calculating the UDP checksum and 259 set it to zero. An encapsulating protocol can always choose to 260 compute the UDP checksum, in which case, its behavior should be as 261 specified above. 263 1. IPv6 protocol stack implementations SHOULD NOT by default 264 allow the new method. The default node receiver behaviour 265 MUST discard all IPv6 packets carrying UDP packets with a zero 266 checksum. 268 2. Implementations MUST provide a way to signal the set of ports 269 that will be enabled to receive UDP datagrams with a zero 270 checksum. An IPv6 node that enables reception of UDP packets 271 with a zero-checksum, MUST enable this only for a specific 272 port or port-range. This may be implemented via a socket API 273 call, or similar mechanism. 275 3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams 276 with a zero-checksum. This should remain the case for any 277 datagram received on a port that does not explicitly enable 278 zero-checksum processing. A port for which zero-checksum has 279 been enabled MUST NOT log the datagram. 281 4. A stack may separately identify UDP datagrams that are 282 discarded with a zero checksum. It SHOULD NOT add these to 283 the standard log, since the endpoint has not been verified. 285 5. UDP Tunnels that encapsulate IP MUST rely on the inner packet 286 integrity checks provided that the tunnel will not 287 significantly increase the rate of corruption of the inner IP 288 packet. If a significantly increased corruption rate can 289 occur, then the tunnel MUST provide an additional integrity 290 verification mechanism. An integrity mechanism is always 291 recommended at the tunnel layer to ensure that corruption 292 rates of the inner most packet are not increased. 294 6. Tunnels that encapsulate Non-IP packets MUST have a CRC or 295 other mechanism for checking packet integrity, unless the 296 Non-IP packet specifically is designed for transmission over 297 lower layers that do not provide any packet integrity 298 guarantee. In particular, the application must be designed so 299 that corruption of this information does not result in 300 accumulated state or incorrect processing of a tunneled 301 payload. 303 7. UDP applications that support use of a zero-checksum, SHOULD 304 NOT rely upon correct reception of the IP and UDP protocol 305 information (including the length of the packet) when decoding 306 and processing the packet payload. In particular, the 307 application must be designed so that corruption of this 308 information does not result in accumulated state or incorrect 309 processing of a tunneled payload. 311 8. If a method proposes recursive tunnels, it MUST provide 312 guidance that is appropriate for all use-cases. Restrictions 313 may be needed to the use of a tunnel encapsulations and the 314 use of recursive tunnels (e.g. Necessary when the endpoint is 315 not verified). 317 9. IPv6 nodes that receive ICMPv6 messages that refer to packets 318 with a zero UDP checksum MUST provide appropriate checks 319 concerning the consistency of the reported packet to verify 320 that the reported packet actually originated from the node, 321 before acting upon the information (e.g. validating the 322 address and port numbers in the ICMPv6 message body). 324 Middleboxes MUST allow IPv6 packets with UDP checksum equal to 325 zero to pass. Implementations of middleboxes MAY allow 326 configuration of specific port ranges for which a zero UDP 327 checksum is valid and may drop IPv6 UDP packets outside those 328 ranges. 330 1.5. Additional Observations 332 The persistence of this issue among a significant number of protocols 333 being developed in the IETF requires a definitive policy. The 334 authors would like to make the following observations: 336 o An empirically-based analysis of the probabilities of packet 337 corruptions (with or without checksums) has not (to our knowledge) 338 been conducted since about 2000. It is now 2010. We strongly 339 suggest that an empirical study is in order, along with an 340 extensive analysis of IPv6 header corruption probabilities. 342 o A key cause of this issue generally is the lack of protocol 343 support in middleboxes. Specifically, new protocols, such as 344 DCCP, are being forced to use UDP tunnels just to traverse an end- 345 to-end path successfully and avoid having their packets dropped by 346 middleboxes. If this were not the case, the use of UDP-lite might 347 become more viable for some (but not necessarily all) lightweight 348 tunneling protocols. 350 o Another cause of this issue is that the UDP checksum is overloaded 351 with the task of protecting the IPv6 header for UDP flows (as it 352 the TCP checksum for TCP flows). Protocols that do not use a 353 pseudo-header approach to computing a checksum or CRC have 354 essentially no protection from misdelivered packets. We suggest 355 that decoupling IPv6 header protection from transport generally 356 should be studied in this workgroup. One approach might be to 357 consider an extension header for IPv6 containing (at least) a 358 header checksum. However, that is beyond the scope of this draft. 360 2. IANA Considerations 362 This document makes no request of IANA. 364 Note to RFC Editor: this section may be removed on publication as an 365 RFC. 367 3. Security Considerations 369 It is of course less work to generate zero-checksum attack packets 370 than ones with full UDP checksums. However, this does not lead to 371 any significant new vulnerabilities as checksums are not a security 372 measure and can be easily generated by any attacker, as properly 373 configured tunnels should check the validity of the inner packet and 374 perform any needed security checks, regardless of the checksum 375 status, and finally as most attacks are generated from compromised 376 hosts which automatically create checksummed packets (in other words, 377 it would generally be more, not less, effort for most attackers to 378 generate zero UDP checksums on the host). 380 4. Acknowledgements 382 We would like to thank Brian Haberman, Magnus Westerlund and Gorry 383 Fairhurst for discussions and reviews. 385 5. Normative References 387 [I-D.ietf-6man-udpzero] 388 Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum 389 Considerations", draft-ietf-6man-udpzero-02 (work in 390 progress), October 2010. 392 [I-D.ietf-lisp] 393 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 394 "Locator/ID Separation Protocol (LISP)", 395 draft-ietf-lisp-09 (work in progress), October 2010. 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 401 Internet Protocol", RFC 2401, November 1998. 403 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 404 (IPv6) Specification", RFC 2460, December 1998. 406 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 407 G. Fairhurst, "The Lightweight User Datagram Protocol 408 (UDP-Lite)", RFC 3828, July 2004. 410 [RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent, 411 "Softwire Security Analysis and Requirements", RFC 5619, 412 August 2009. 414 Authors' Addresses 416 Marshall Eubanks 417 Iformata Communications 419 Phone: +1-703-501-4376 420 Fax: 421 Email: marshall.eubanks@iformata.com 422 URI: 424 P.F. Chimento 425 Johns Hopkins University Applied Physics Laboratory 426 11100 Johns Hopkins Road 427 Laurel, MD 20723 428 USA 430 Phone: +1-443-778-1743 431 Fax: 432 Email: Philip.Chimento@jhuapl.edu 433 URI: