idnits 2.17.1 draft-ietf-6man-udpchecksums-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 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 (March 7, 2011) is 4771 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 411, but no explicit reference was found in the text == Unused Reference: 'RFC3828' is defined on line 417, 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-02 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-09 == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-10 Summary: 2 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: September 8, 2011 Johns Hopkins University Applied 6 Physics Laboratory 7 March 7, 2011 9 UDP Checksums for Tunneled Packets 10 draft-ietf-6man-udpchecksums-00 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 September 8, 2011. 40 Copyright Notice 42 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . 10 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 5.1. Normative References . . . . . . . . . . . . . . . . . . . 10 68 5.2. Informative References . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 With the rapid growth of the Internet, tunnel protocols have become 74 increasingly important in the deployment of new transport layer 75 protocols. Tunneled protocols can be deployed rapidly, while the 76 time to upgrade and deploy a critical mass of routers, switches and 77 end hosts on the global Internet for a new transport protocol is now 78 measured in decades. At the same time, the increasing use of 79 firewalls and other security related middleware means that truly new 80 tunnel protocols are also unlikely to be deployable in a reasonable 81 time frame, which has lead to an increasing interest in and use of 82 UDP-based tunneling protocols. In such protocols, there is an 83 encapsulated "inner" packet, and the "outer" packet carrying the 84 tunneled inner packet is a UDP packet, which can pass through 85 firewalls and other middleware filtering that is a fact of life on 86 the current Internet. 88 As tunnel endpoints may be routers or middleware aggregating traffic 89 from large numbers of tunnel users, the computation of an additional 90 checksum on the outer UDP packet, when protected, is seen to be an 91 unwarranted burden on the nodes implementing lightweight tunneling 92 protocols, especially if the inner packet(s) are already protected by 93 a checksum. In IPv4, there is a checksum on the IP packet itself, 94 and the checksum on the outer UDP packet can be set to zero. However 95 in IPv6 there is not a checksum on the IP packet and RFC 2460 96 [RFC2460] explicitly states that IPv6 receivers MUST discard UDP 97 packets with a 0 checksum. So, while sending a UDP packet with a 0 98 checksum is permitted in IPv4 packets, it is explicitly forbidden in 99 IPv6 packets. In order to meet the needs of the deployers of IPv6 100 UDP tunnels, this document modifies RFC 2460 to allow for the 101 ignoring of UDP checksums under constrained situations (IPv6 102 tunneling where the inner packet exists and has a checksum), based on 103 the considerations set forth in [I-D.ietf-6man-udpzero]. 105 While the origin of this I-D is the problem raised by the draft 106 titled "Automatic IP Multicast Without Explicit Tunnels", also known 107 as "AMT," [I-D.ietf-mboned-auto-multicast] we expect it to have wide 108 applicability, immediately to LISP [I-D.ietf-lisp], and also to other 109 tunneling protocols to come out of Softwires and other IETF Working 110 Groups. 112 Since the first version of this draft, the need for an efficient, 113 lightweight UDP tunneling mechanism has increased. Indeed, other 114 workgroups, notably LISP [I-D.ietf-lisp] and Softwires [RFC5619] have 115 also expressed a need to have exceptions to the RFC 2460 prohibition. 116 More recently, a discussion on the DCCP mailing list covered the UDP 117 over IPv6 checksum issues. Other users of UDP as a tunneling 118 protocol, for example, L2TP and Softwires may benefit from a 119 relaxation of the RFC 2460 restriction. 121 1.1. Some Terminology 123 For the remainder of this draft, we discuss only IPv6, since this 124 problem does not exist for IPv4. So any reference to 'IP' should be 125 understood as a reference to IPv6. 127 Although we will try to avoid them when possible, we may use the 128 terms "tunneling" and "tunneled" as adjectives when describing 129 packets. When we refer to 'tunneling packets' we refer to the outer 130 packet header that provides the tunneling function. When we refer to 131 'tunneled packets' we refer to the inner packet, i.e. the packet 132 being carried in the tunnel. 134 1.2. Problem Statement 136 The argument is that since in the case of AMT multicast packets 137 already have a UDP header with a checksum, there is no additional 138 benefit and indeed some cost to nodes to both compute and check the 139 UDP checksum of the outer (encapsulating) header. Consequently, IPv6 140 should make an exception to the rule that the UDP checksum MUST not 141 be 0, and allow tunneling protocols to set the checksum field of the 142 outer header only to 0 and skip both the sender and receiver 143 computation. 145 1.3. Discussion 147 The draft [I-D.ietf-6man-udpzero] does an excellent job of discussing 148 all the issues related to allowing UDP over IPv6 to have a valid 149 checksum of zero. We will not repeat that work here. 151 In Section 5.1 of [I-D.ietf-6man-udpzero], the authors propose nine 152 (9) constraints on the usage of a zero checksum for UDP over IPv6. 153 We agree with the restrictions proposed, and in fact proposed some of 154 those restrictions ourselves in the previous version of the current 155 draft. These restrictions are incorporated into the proposed changes 156 below. 158 As has been pointed out in [I-D.ietf-6man-udpzero] and in many 159 mailing lists, there is still the possibility of deep-inspection 160 firewall devices or other middleboxes actually checking the UDP 161 checksum field of the outer packet and discarding the tunneling 162 packets. This is would be an issue also for legacy systems which 163 have not implemented the change in the IPv6 specification. So in any 164 case, there may be packet loss of lightweight tunneling packets 165 because of mixed new-rule and old-rule nodes. 167 As an example, we discuss how can errors be detected and handled in a 168 lightweight UDP tunneling protocol when the checksum protection is 169 disabled. Note that other (non-tunneling) protocols may have 170 different approaches. We suggest that the following could be an 171 approach to this problem: 173 o Context (i.e. tunneling state) should be established via 174 application PDUs that are carried in checksummed UDP packets. 175 That is, any control packets flowing between the tunnel endpoints 176 should be protected by UDP checksums. The control packets can 177 also contain any negotiation that is necessary to set up the 178 endpoint/adapters to accept UDP packets with a zero checksum. 180 o Only UDP packets containing tunneled packets should have a UDP 181 checksum equal to zero. 183 o UDP keep-alive packets with checksum zero can be sent to validate 184 paths, given that paths between tunnel endpoints can change and so 185 middleboxes in the path may vary during the life of the 186 association. Paths with middleboxes that are intolerant of a UDP 187 checksum of zero will drop the keep-alives and the endpoints will 188 discover that. Note that this need only be done per tunnel 189 endpoint pair, not per tunnel context. 191 o Corruption of the encapsulating IPv6 source address, destination 192 address and/or the UDP source port, destination port fields : If 193 the 9 restrictions in [I-D.ietf-6man-udpzero] are followed, the 194 inner packets (tunneled packets) should be protected and run the 195 usual (presumably small) risk of having undetected corruption(s). 196 If lightweight tunneling protocol contexts contain (at a minumum) 197 source and destination IP addresses and source and destination 198 ports, there are 16 possible corruption outcomes. We note that 199 these outcomes not equally likely, as most require multiple bit 200 errors with errored bits in separate fields. The possible 201 corruption outcomes fall out this way: 203 * Half of the 16 possible corruption combinations have a 204 corrupted destination address. If the incorrect destination is 205 reached and the node doesn't have an application for the 206 destination port, the packet will be dropped. If the 207 application at the incorrect destination is the same 208 lightweight tunneling protocol and if it has a matching context 209 (which can be assumed to be a very low probability event) the 210 inner packet will be decapsulated and forwarded. If it is some 211 other application, with very high probability, the application 212 will not recognize the contents of the packet. 214 * Half of the 8 possible corruption combinations with a correct 215 destination address have a corrupted source address. If the 216 tunnel contexts contain all elements of the address-port 217 4-tuple, then the liklihood is that this corruption will be 218 detected. 220 * Of the remaining 4 possibilities, with valid source and 221 destination IPv6 addresses, 1 has all 4 fields valid, the other 222 three have one or both ports corrupted. Again, if the 223 tunneling endpoint context contains sufficient information, 224 these error should be detected with high probability. 226 o Corruption of source-fragmented encapsulating packets: In this 227 case, a tunneling protocol may reassemble fragments associated 228 with the wrong context at the right tunnel endpoint, or it may 229 reassemble fragments associated with a context at the wrong tunnel 230 endpoint, or corrupted fragments may be reassembled at the right 231 context at the right tunnel endpoint. In each of these cases, the 232 IPv6 length of the encapsulating header may be checked (though 233 [I-D.ietf-6man-udpzero] points out the weakness in this check). 234 In addition, if the encapsulated packet is protected by a 235 transport (or other) checksum, these errors can be detected (with 236 some probability). 238 While this is not a perfect solution, it can reduce the risks of 239 relaxing the UDP checksum requirement for IPv6. 241 1.4. Recommended Solution 243 There is a need that a UDP checksum of zero could be allowed on the 244 outer encapsulating packet of a lightweight tunneling protocol. This 245 would imply that UDP endpoints handling that protocol must change 246 their behavior and not discard UDP packets received with a 0 checksum 247 on the outer packet. We also recommend that the constraints in 248 Section 5.1 of [I-D.ietf-6man-udpzero] be adopted. 250 Specifically, this draft proposes that the text in [RFC2460] Section 251 8.1, 4th bullet be amended. We refer to the following text: 253 "Unlike IPv4, when UDP packets are originated by an IPv6 node, the 254 UDP checksum is not optional. That is, whenever originating a UDP 255 packet, an IPv6 node must compute a UDP checksum over the packet and 256 the pseudo-header, and, if that computation yields a result of zero, 257 it must be changed to hex FFFF for placement in the UDP header. IPv6 258 receivers must discard UDP packets containing a zero checksum, and 259 should log the error." 261 This item should be taken out of the bullet list and should be 262 modified as follows: 264 Whenever originating a UDP packet, an IPv6 node SHOULD compute a 265 UDP checksum over the packet and the pseudo-header, and, if that 266 computation yields a result of zero, it must be changed to hex 267 FFFF for placement in the UDP header. IPv6 receivers SHOULD 268 discard UDP packets containing a zero checksum, and SHOULD log the 269 error. However, some protocols, such as lightweight tunneling 270 protocols that use UDP as a tunnel encapsulation, MAY omit 271 computing the UDP checksum of the encapsulating UDP header and set 272 it to zero, subject to the following constraints (from 273 [I-D.ietf-6man-udpzero]). In cases, where the encapsulating 274 protocol uses a zero checksum for UDP, the receiver of packets in 275 the allowed port range MUST NOT discard packets with a UDP 276 checksum of zero. Note that these constraints apply only to 277 encapsulating protocols that omit calculating the UDP checksum and 278 set it to zero. An encapsulating protocol can always choose to 279 compute the UDP checksum, in which case, its behavior should be as 280 specified above. 282 1. IPv6 protocol stack implementations SHOULD NOT by default 283 allow the new method. The default node receiver behaviour 284 MUST discard all IPv6 packets carrying UDP packets with a zero 285 checksum. 287 2. Implementations MUST provide a way to signal the set of ports 288 that will be enabled to receive UDP datagrams with a zero 289 checksum. An IPv6 node that enables reception of UDP packets 290 with a zero-checksum, MUST enable this only for a specific 291 port or port-range. This may be implemented via a socket API 292 call, or similar mechanism. 294 3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams 295 with a zero-checksum. This should remain the case for any 296 datagram received on a port that does not explicitly enable 297 zero-checksum processing. A port for which zero-checksum has 298 been enabled MUST NOT log the datagram. 300 4. A stack may separately identify UDP datagrams that are 301 discarded with a zero checksum. It SHOULD NOT add these to 302 the standard log, since the endpoint has not been verified. 304 5. UDP Tunnels that encapsulate IP MUST rely on the inner packet 305 integrity checks provided that the tunnel will not 306 significantly increase the rate of corruption of the inner IP 307 packet. If a significantly increased corruption rate can 308 occur, then the tunnel MUST provide an additional integrity 309 verification mechanism. An integrity mechanism is always 310 recommended at the tunnel layer to ensure that corruption 311 rates of the inner most packet are not increased. 313 6. Tunnels that encapsulate Non-IP packets MUST have a CRC or 314 other mechanism for checking packet integrity, unless the 315 Non-IP packet specifically is designed for transmission over 316 lower layers that do not provide any packet integrity 317 guarantee. In particular, the application must be designed so 318 that corruption of this information does not result in 319 accumulated state or incorrect processing of a tunneled 320 payload. 322 7. UDP applications that support use of a zero-checksum, SHOULD 323 NOT rely upon correct reception of the IP and UDP protocol 324 information (including the length of the packet) when decoding 325 and processing the packet payload. In particular, the 326 application must be designed so that corruption of this 327 information does not result in accumulated state or incorrect 328 processing of a tunneled payload. 330 8. If a method proposes recursive tunnels, it MUST provide 331 guidance that is appropriate for all use-cases. Restrictions 332 may be needed to the use of a tunnel encapsulations and the 333 use of recursive tunnels (e.g. Necessary when the endpoint is 334 not verified). 336 9. IPv6 nodes that receive ICMPv6 messages that refer to packets 337 with a zero UDP checksum MUST provide appropriate checks 338 concerning the consistency of the reported packet to verify 339 that the reported packet actually originated from the node, 340 before acting upon the information (e.g. validating the 341 address and port numbers in the ICMPv6 message body). 343 Middleboxes MUST allow IPv6 packets with UDP checksum equal to 344 zero to pass. Implementations of middleboxes MAY allow 345 configuration of specific port ranges for which a zero UDP 346 checksum is valid and may drop IPv6 UDP packets outside those 347 ranges. 349 1.5. Additional Observations 351 The persistence of this issue among a significant number of protocols 352 being developed in the IETF requires a definitive policy. The 353 authors would like to make the following observations: 355 o An empirically-based analysis of the probabilities of packet 356 corruptions (with or without checksums) has not (to our knowledge) 357 been conducted since about 2000. It is now 2011. We strongly 358 suggest that an empirical study is in order, along with an 359 extensive analysis of IPv6 header corruption probabilities. 361 o A key cause of this issue generally is the lack of protocol 362 support in middleboxes. Specifically, new protocols, such as 363 DCCP, are being forced to use UDP tunnels just to traverse an end- 364 to-end path successfully and avoid having their packets dropped by 365 middleboxes. If this were not the case, the use of UDP-lite might 366 become more viable for some (but not necessarily all) lightweight 367 tunneling protocols. 369 o Another cause of this issue is that the UDP checksum is overloaded 370 with the task of protecting the IPv6 header for UDP flows (as it 371 the TCP checksum for TCP flows). Protocols that do not use a 372 pseudo-header approach to computing a checksum or CRC have 373 essentially no protection from misdelivered packets. We suggest 374 that decoupling IPv6 header protection from transport generally 375 should be studied in this workgroup. One approach might be to 376 consider an extension header for IPv6 containing (at least) a 377 header checksum. However, that is beyond the scope of this draft. 379 2. IANA Considerations 381 This document makes no request of IANA. 383 Note to RFC Editor: this section may be removed on publication as an 384 RFC. 386 3. Security Considerations 388 It is of course less work to generate zero-checksum attack packets 389 than ones with full UDP checksums. However, this does not lead to 390 any significant new vulnerabilities as checksums are not a security 391 measure and can be easily generated by any attacker, as properly 392 configured tunnels should check the validity of the inner packet and 393 perform any needed security checks, regardless of the checksum 394 status, and finally as most attacks are generated from compromised 395 hosts which automatically create checksummed packets (in other words, 396 it would generally be more, not less, effort for most attackers to 397 generate zero UDP checksums on the host). 399 4. Acknowledgements 401 We would like to thank Brian Haberman, Magnus Westerlund and Gorry 402 Fairhurst for discussions and reviews. 404 5. References 406 5.1. Normative References 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, March 1997. 411 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 412 Internet Protocol", RFC 2401, November 1998. 414 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 415 (IPv6) Specification", RFC 2460, December 1998. 417 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 418 G. Fairhurst, "The Lightweight User Datagram Protocol 419 (UDP-Lite)", RFC 3828, July 2004. 421 [RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent, 422 "Softwire Security Analysis and Requirements", RFC 5619, 423 August 2009. 425 5.2. Informative References 427 [I-D.ietf-6man-udpzero] 428 Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum 429 Considerations", draft-ietf-6man-udpzero-02 (work in 430 progress), October 2010. 432 [I-D.ietf-lisp] 433 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 434 "Locator/ID Separation Protocol (LISP)", 435 draft-ietf-lisp-09 (work in progress), October 2010. 437 [I-D.ietf-mboned-auto-multicast] 438 Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. 439 Pusateri, "Automatic IP Multicast Without Explicit Tunnels 440 (AMT)", draft-ietf-mboned-auto-multicast-10 (work in 441 progress), March 2010. 443 Authors' Addresses 445 Marshall Eubanks 446 AmericaFree.TV LLC 447 P.O. Box 141 448 Clifton, Virginia 20124 449 USA 451 Phone: +1-703-501-4376 452 Fax: 453 Email: tme@americafree.tv 454 URI: http://www.americafree.tv 456 P.F. Chimento 457 Johns Hopkins University Applied Physics Laboratory 458 11100 Johns Hopkins Road 459 Laurel, MD 20723 460 USA 462 Phone: +1-443-778-1743 463 Fax: 464 Email: Philip.Chimento@jhuapl.edu 465 URI: