idnits 2.17.1 draft-ietf-6man-udpchecksums-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2460]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 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 31, 2011) is 4532 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 427, but no explicit reference was found in the text == Unused Reference: 'RFC3828' is defined on line 433, 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) == Outdated reference: A later version (-12) exists of draft-ietf-6man-udpzero-04 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-15 == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-11 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 AmericaFree.TV LLC 4 Intended status: Standards Track P. Chimento 5 Expires: May 3, 2012 Johns Hopkins University Applied 6 Physics Laboratory 7 October 31, 2011 9 UDP Checksums for Tunneled Packets 10 draft-ietf-6man-udpchecksums-01 12 Abstract 14 This document provides an update of RFC 2460[RFC2460] in order to 15 improve the performance of IPv6 in an increasingly important use 16 case, the use of tunneling to carry new transport protocols. The 17 performance improvement is obtained by relaxing the IPv6 UDP checksum 18 requirement for suitable tunneling protocol where header information 19 is protected on the "inner" packet being carried. This relaxation 20 removes the overhead associated with the computation of UDP checksums 21 on tunneled IPv6 packets and thereby improves the efficiency of the 22 traversal of firewalls and other network middleware by such new 23 protocols. We describe how the IPv6 UDP checksum requirement can be 24 relaxed in the situation where the encapsulated packet itself 25 contains a checksum, the limitations and risks of this approach, and 26 provides restrictions on the use of this relaxation to mitigate these 27 risks. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 3, 2012. 51 Copyright Notice 53 Copyright (c) 2011 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Some Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. The Zero-Checksum Solution . . . . . . . . . . . . . . . . . . 7 73 6. Additional Observations . . . . . . . . . . . . . . . . . . . 10 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 10.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 This work constitutes the first upgrade of RFC 2460[RFC2460], in 85 order to improve the performance of IPv6 with transport layer 86 protocols carried encapsulated in tunnels. With the rapid growth of 87 the Internet, tunneling protocols have become increasingly important 88 to enable the deployment of new transport layer protocols. Tunneled 89 protocols can be deployed rapidly, while the time to upgrade and 90 deploy a critical mass of routers, switches and end hosts on the 91 global Internet for a new transport protocol is now measured in 92 decades. At the same time, the increasing use of firewalls and other 93 security related middleware means that truly new tunnel protocols, 94 with new protocol numbers, are also unlikely to be deployable in a 95 reasonable time frame, which has resulted in an increasing interest 96 in and use of UDP-based tunneling protocols. In such protocols, 97 there is an encapsulated "inner" packet, and the "outer" packet 98 carrying the tunneled inner packet is a UDP packet, which can pass 99 through firewalls and other middleware filtering that is a fact of 100 life on the current Internet. 102 As tunnel endpoints may be routers or middleware aggregating traffic 103 from large numbers of tunnel users, the computation of an additional 104 checksum on the outer UDP packet, when protected, is seen to be an 105 unwarranted burden on the nodes implementing lightweight tunneling 106 protocols, especially if the inner packet(s) are already protected by 107 a checksum. In IPv4, there is a checksum on the IP packet itself, 108 and the checksum on the outer UDP packet can be set to zero. However 109 in IPv6 there is not a checksum on the IP packet and RFC 2460 110 [RFC2460] explicitly states that IPv6 receivers MUST discard UDP 111 packets with a 0 checksum. So, while sending a UDP packet with a 0 112 checksum is permitted in IPv4 packets, it is explicitly forbidden in 113 IPv6 packets. In order to meet the needs of the deployers of IPv6 114 UDP tunnels, this document modifies RFC 2460 to allow for the 115 ignoring of UDP checksums under constrained situations (IPv6 116 tunneling where the inner packet exists and has a checksum), based on 117 the considerations set forth in [I-D.ietf-6man-udpzero]. 119 While the origin of this I-D is the problem raised by the draft 120 titled "Automatic IP Multicast Without Explicit Tunnels", also known 121 as "AMT," [I-D.ietf-mboned-auto-multicast] we expect it to have wide 122 applicability, immediately to LISP [I-D.ietf-lisp], and also to other 123 tunneling protocols to come out of Softwires and other IETF Working 124 Groups. 126 Since the first version of this document, the need for an efficient, 127 lightweight UDP tunneling mechanism has increased. Indeed, other 128 workgroups, notably LISP [I-D.ietf-lisp] and Softwires [RFC5619] have 129 also expressed a need to have exceptions to the RFC 2460 prohibition. 131 Other users of UDP as a tunneling protocol, for example, L2TP and 132 Softwires may benefit from a relaxation of the RFC 2460 restriction. 134 The third version of this document benefited from a close read by 135 Magnus Westerlund and Gorry Fairhurst. 137 2. Some Terminology 139 For the remainder of this document, we discuss only IPv6, since this 140 problem does not exist for IPv4. So any reference to 'IP' should be 141 understood as a reference to IPv6. 143 Although we will try to avoid them when possible, we may use the 144 terms "tunneling" and "tunneled" as adjectives when describing 145 packets. When we refer to 'tunneling packets' we refer to the outer 146 packet header that provides the tunneling function. When we refer to 147 'tunneled packets' we refer to the inner packet, i.e. the packet 148 being carried in the tunnel. 150 3. Problem Statement 152 The argument is that since in the case of AMT multicast packets 153 already have a UDP header with a checksum, there is no additional 154 benefit and indeed some cost to nodes to both compute and check the 155 UDP checksum of the outer (encapsulating) header. Consequently, IPv6 156 should make an exception to the rule that the UDP checksum MUST not 157 be 0, and allow tunneling protocols to set the checksum field of the 158 outer header only to 0 and skip both the sender and receiver 159 computation. 161 4. Discussion 163 [I-D.ietf-6man-udpzero] describes the issues related to allowing UDP 164 over IPv6 to have a valid checksum of zero and is not repeated here. 166 In Section 5.1 of [I-D.ietf-6man-udpzero], the authors propose nine 167 (9) constraints on the usage of a zero checksum for UDP over IPv6. 168 We agree with the restrictions proposed, and in fact proposed some of 169 those restrictions ourselves in the previous version of the current 170 draft. These restrictions are incorporated into the proposed changes 171 below. 173 As has been pointed out in [I-D.ietf-6man-udpzero] and in many 174 mailing lists, there is still the possibility of deep-inspection 175 firewall devices or other middleboxes actually checking the UDP 176 checksum field of the outer packet and discarding the tunneling 177 packets. This is would be an issue also for legacy systems which 178 have not implemented the change in the IPv6 specification. So in any 179 case, there may be packet loss of lightweight tunneling packets 180 because of mixed new-rule and old-rule nodes. 182 As an example, we discuss how can errors be detected and handled in a 183 lightweight UDP tunneling protocol when the checksum protection is 184 disabled. Note that other (non-tunneling) protocols may have 185 different approaches. We suggest that the following could be an 186 approach to this problem: 188 o Context (i.e. tunneling state) should be established via 189 application PDUs that are carried in checksummed UDP packets. 190 That is, any control packets flowing between the tunnel endpoints 191 should be protected by UDP checksums. The control packets can 192 also contain any negotiation that is necessary to set up the 193 endpoint/adapters to accept UDP packets with a zero checksum. 195 o Only UDP packets containing tunneled packets should have a UDP 196 checksum equal to zero. 198 o UDP keep-alive packets with checksum zero can be sent to validate 199 paths, given that paths between tunnel endpoints can change and so 200 middleboxes in the path may vary during the life of the 201 association. Paths with middleboxes that are intolerant of a UDP 202 checksum of zero will drop the keep-alives and the endpoints will 203 discover that. Note that this need only be done per tunnel 204 endpoint pair, not per tunnel context. Keep-alive traffic SHOULD 205 include both packets with tunnel checksums and packets with 206 checksums equal to zero to enable the remote end to distinguish 207 between path failures and the blockage of packets with checksum 208 equal to zero. 210 o Corruption of the encapsulating IPv6 source address, destination 211 address and/or the UDP source port, destination port fields : If 212 the 9 restrictions in [I-D.ietf-6man-udpzero] are followed, the 213 inner packets (tunneled packets) should be protected and run the 214 usual (presumably small) risk of having undetected corruption(s). 215 If lightweight tunneling protocol contexts contain (at a minimum) 216 source and destination IP addresses and source and destination 217 ports, there are 16 possible corruption outcomes. We note that 218 these outcomes not equally likely, as most require multiple bit 219 errors with errored bits in separate fields. The possible 220 corruption outcomes fall out this way: 222 * Half of the 16 possible corruption combinations have a 223 corrupted destination address. If the incorrect destination is 224 reached and the node doesn't have an application for the 225 destination port, the packet will be dropped. If the 226 application at the incorrect destination is the same 227 lightweight tunneling protocol and if it has a matching context 228 (which can be assumed to be a very low probability event) the 229 inner packet will be decapsulated and forwarded. If it is some 230 other application, with very high probability, the application 231 will not recognize the contents of the packet. 233 * Half of the 8 possible corruption combinations with a correct 234 destination address have a corrupted source address. If the 235 tunnel contexts contain all elements of the address-port 236 4-tuple, then the likelihood is that this corruption will be 237 detected. 239 * Of the remaining 4 possibilities, with valid source and 240 destination IPv6 addresses, 1 has all 4 fields valid, the other 241 three have one or both ports corrupted. Again, if the 242 tunneling endpoint context contains sufficient information, 243 these error should be detected with high probability. 245 o Corruption of source-fragmented encapsulating packets: In this 246 case, a tunneling protocol may reassemble fragments associated 247 with the wrong context at the right tunnel endpoint, or it may 248 reassemble fragments associated with a context at the wrong tunnel 249 endpoint, or corrupted fragments may be reassembled at the right 250 context at the right tunnel endpoint. In each of these cases, the 251 IPv6 length of the encapsulating header may be checked (though 252 [I-D.ietf-6man-udpzero] points out the weakness in this check). 253 In addition, if the encapsulated packet is protected by a 254 transport (or other) checksum, these errors can be detected (with 255 some probability). 257 While this is not a perfect solution, it can reduce the risks of 258 relaxing the UDP checksum requirement for IPv6. 260 5. The Zero-Checksum Solution 262 The solution to the overhead associated with UDP packets carrying 263 encapsulated tunnel traffic is to allow a UDP checksum of zero on the 264 outer encapsulating packet of a lightweight tunneling protocol. UDP 265 endpoints that implement this solution MUST change their behavior and 266 not discard UDP packets received with a 0 checksum on the outer 267 packet of tunneling protocols. If this is done constraints in 268 Section 5.1 of [I-D.ietf-6man-udpzero] also MUST be adopted. 270 Specifically, the text in [RFC2460] Section 8.1, 4th bullet is 271 amended. We refer to the following text: 273 "Unlike IPv4, when UDP packets are originated by an IPv6 node, the 274 UDP checksum is not optional. That is, whenever originating a UDP 275 packet, an IPv6 node must compute a UDP checksum over the packet and 276 the pseudo-header, and, if that computation yields a result of zero, 277 it must be changed to hex FFFF for placement in the UDP header. IPv6 278 receivers must discard UDP packets containing a zero checksum, and 279 should log the error." 281 This item should be taken out of the bullet list and should be 282 modified as follows: 284 Whenever originating a UDP packet, an IPv6 node SHOULD compute a 285 UDP checksum over the packet and the pseudo-header, and, if that 286 computation yields a result of zero, it must be changed to hex 287 FFFF for placement in the UDP header. IPv6 receivers SHOULD 288 discard UDP packets containing a zero checksum, and SHOULD log the 289 error. However, some protocols, such as lightweight tunneling 290 protocols that use UDP as a tunnel encapsulation, MAY omit 291 computing the UDP checksum of the encapsulating UDP header and set 292 it to zero, subject to the constraints described in 293 [I-D.ietf-6man-udpzero]. In cases where the encapsulating 294 protocol uses a zero checksum for UDP, the receiver of packets 295 sent to a port enabled to receive zero-checksum packets MUST NOT 296 discard packets solely for having a UDP checksum of zero. Note 297 that these constraints apply only to encapsulating protocols that 298 omit calculating the UDP checksum and set it to zero. An 299 encapsulating protocol can always choose to compute the UDP 300 checksum, in which case, its behavior should be as specified 301 originally. 303 1. IPv6 protocol stack implementations SHOULD NOT by default 304 allow the new method. The default node receiver behavior MUST 305 discard all IPv6 packets carrying UDP packets with a zero 306 checksum. 308 2. Implementations MUST provide a way to signal the set of ports 309 that will be enabled to receive UDP datagrams with a zero 310 checksum. An IPv6 node that enables reception of UDP packets 311 with a zero-checksum, MUST enable this only for a specific 312 port or port-range. This may be implemented via a socket API 313 call, or similar mechanism. 315 3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams 316 with a zero-checksum. A port for which zero-checksum has been 317 enabled MUST NOT log zero-checksum datagrams for that reason 318 (of course, there might be other reasons to log such packets). 320 4. A stack may separately identify UDP datagrams that are 321 discarded with a zero checksum. It SHOULD NOT add these to 322 the standard log, since the endpoint has not been verified. 324 5. UDP Tunnels that encapsulate IP may rely on the inner packet 325 integrity checks provided that the tunnel will not 326 significantly increase the rate of corruption of the inner IP 327 packet. If a significantly increased corruption rate can 328 occur, then the tunnel MUST provide an additional integrity 329 verification mechanism. An integrity mechanism is always 330 recommended at the tunnel layer to ensure that corruption 331 rates of the inner most packet are not increased. 333 6. Tunnels that encapsulate Non-IP packets MUST have a CRC or 334 other mechanism for checking packet integrity, unless the 335 Non-IP packet specifically is designed for transmission over 336 lower layers that do not provide any packet integrity 337 guarantee. In particular, the application must be designed so 338 that corruption of this information does not result in 339 accumulated state or incorrect processing of a tunneled 340 payload. 342 7. UDP applications that support use of a zero-checksum, SHOULD 343 NOT rely upon correct reception of the IP and UDP protocol 344 information (including the length of the packet) when decoding 345 and processing the packet payload. In particular, the 346 application must be designed so that corruption of this 347 information does not result in accumulated state or incorrect 348 processing of a tunneled payload. 350 8. If a method proposes recursive tunnels, it MUST provide 351 guidance that is appropriate for all use-cases. Restrictions 352 may be needed to the use of a tunnel encapsulations and the 353 use of recursive tunnels (e.g. Necessary when the endpoint is 354 not verified). 356 9. IPv6 nodes that receive ICMPv6 messages that refer to packets 357 with a zero UDP checksum MUST provide appropriate checks 358 concerning the consistency of the reported packet to verify 359 that the reported packet actually originated from the node, 360 before acting upon the information (e.g. validating the 361 address and port numbers in the ICMPv6 message body). 363 Middleboxes MUST allow IPv6 packets with UDP checksum equal to 364 zero to pass. Implementations of middleboxes MAY allow 365 configuration of specific port ranges for which a zero UDP 366 checksum is valid and may drop IPv6 UDP packets outside those 367 ranges. 369 6. Additional Observations 371 The persistence of this issue among a significant number of protocols 372 being developed in the IETF requires a definitive policy. The 373 authors would like to make the following observations: 375 o An empirically-based analysis of the probabilities of packet 376 corruptions (with or without checksums) has not (to our knowledge) 377 been conducted since about 2000. It is now 2011. We strongly 378 suggest that an empirical study is in order, along with an 379 extensive analysis of IPv6 header corruption probabilities. 381 o A key cause of this issue generally is the lack of protocol 382 support in middleboxes. Specifically, new protocols, such as 383 LISP, are being forced to use UDP tunnels just to traverse an end- 384 to-end path successfully and avoid having their packets dropped by 385 middleboxes. If this were not the case, the use of UDP-lite might 386 become more viable for some (but not necessarily all) lightweight 387 tunneling protocols. 389 o Another cause of this issue is that the UDP checksum is overloaded 390 with the task of protecting the IPv6 header for UDP flows (as it 391 the TCP checksum for TCP flows). Protocols that do not use a 392 pseudo-header approach to computing a checksum or CRC have 393 essentially no protection from misdelivered packets. 395 7. IANA Considerations 397 This document makes no request of IANA. 399 Note to RFC Editor: this section may be removed on publication as an 400 RFC. 402 8. Security Considerations 404 It is of course less work to generate zero-checksum attack packets 405 than ones with full UDP checksums. However, this does not lead to 406 any significant new vulnerabilities as checksums are not a security 407 measure and can be easily generated by any attacker, as properly 408 configured tunnels should check the validity of the inner packet and 409 perform any needed security checks, regardless of the checksum 410 status, and finally as most attacks are generated from compromised 411 hosts which automatically create checksummed packets (in other words, 412 it would generally be more, not less, effort for most attackers to 413 generate zero UDP checksums on the host). 415 9. Acknowledgements 417 We would like to thank Brian Haberman, Magnus Westerlund and Gorry 418 Fairhurst for discussions and reviews. 420 10. References 422 10.1. Normative References 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, March 1997. 427 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 428 Internet Protocol", RFC 2401, November 1998. 430 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 431 (IPv6) Specification", RFC 2460, December 1998. 433 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 434 G. Fairhurst, "The Lightweight User Datagram Protocol 435 (UDP-Lite)", RFC 3828, July 2004. 437 [RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent, 438 "Softwire Security Analysis and Requirements", RFC 5619, 439 August 2009. 441 10.2. Informative References 443 [I-D.ietf-6man-udpzero] 444 Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum 445 Considerations", draft-ietf-6man-udpzero-04 (work in 446 progress), October 2011. 448 [I-D.ietf-lisp] 449 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 450 "Locator/ID Separation Protocol (LISP)", 451 draft-ietf-lisp-15 (work in progress), July 2011. 453 [I-D.ietf-mboned-auto-multicast] 454 Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. 455 Pusateri, "Automatic IP Multicast Without Explicit Tunnels 456 (AMT)", draft-ietf-mboned-auto-multicast-11 (work in 457 progress), July 2011. 459 Authors' Addresses 461 Marshall Eubanks 462 AmericaFree.TV LLC 463 P.O. Box 141 464 Clifton, Virginia 20124 465 USA 467 Phone: +1-703-501-4376 468 Fax: 469 Email: marshall.eubanks@gmail.com 471 P.F. Chimento 472 Johns Hopkins University Applied Physics Laboratory 473 11100 Johns Hopkins Road 474 Laurel, MD 20723 475 USA 477 Phone: +1-443-778-1743 478 Fax: 479 Email: Philip.Chimento@jhuapl.edu 480 URI: