idnits 2.17.1 draft-ietf-6man-udpchecksums-05.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 draft header indicates that this document updates RFC2460, but the abstract doesn't seem to directly say this. It does mention RFC2460 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2460, updated by this document, for RFC5378 checks: 1997-07-30) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2012) is 4202 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) == Outdated reference: A later version (-12) exists of draft-ietf-6man-udpzero-07 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-24) exists of draft-ietf-lisp-23 == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-14 -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). 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 Updates: 2460 (if approved) P. Chimento 5 Intended status: Standards Track Johns Hopkins University Applied 6 Expires: April 25, 2013 Physics Laboratory 7 M. Westerlund 8 Ericsson 9 October 22, 2012 11 UDP Checksums for Tunneled Packets 12 draft-ietf-6man-udpchecksums-05 14 Abstract 16 This document provides an update of the Internet Protocol version 6 17 (IPv6) specification (RFC2460) to improve the performance of IPv6 in 18 the use case when a tunnel protocol uses UDP with IPv6 to tunnel 19 packets. The performance improvement is obtained by relaxing the 20 IPv6 UDP checksum requirement for suitable tunneling protocol where 21 header information is protected on the "inner" packet being carried. 22 This relaxation removes the overhead associated with the computation 23 of UDP checksums on IPv6 packets used to carry tunnel protocols and 24 thereby improves the efficiency of the traversal of firewalls and 25 other network middleboxes by such protocols. We describe how the 26 IPv6 UDP checksum requirement can be relaxed in the situation where 27 the encapsulated packet itself contains a checksum, the limitations 28 and risks of this approach, and define restrictions on the use of 29 this relaxation to mitigate these risks. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 25, 2013. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Some Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 5. The Zero-Checksum Update . . . . . . . . . . . . . . . . . . . 7 70 6. Additional Observations . . . . . . . . . . . . . . . . . . . 8 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 This work constitutes an update of the Internet Protocol Version 6 82 (IPv6) Specification [RFC2460], in the use case when a tunnel 83 protocol uses UDP with IPv6 to tunnel packets. With the rapid growth 84 of the Internet, tunneling protocols have become increasingly 85 important to enable the deployment of new protocols. Tunneled 86 protocols can be deployed rapidly, while the time to upgrade and 87 deploy a critical mass of routers, switches and end hosts on the 88 global Internet for a new protocol is now measured in decades. At 89 the same time, the increasing use of firewalls and other security 90 related middleboxes means that truly new tunnel protocols, with new 91 protocol numbers, are also unlikely to be deployable in a reasonable 92 time frame, which has resulted in an increasing interest in and use 93 of UDP-based tunneling protocols. In such protocols, there is an 94 encapsulated "inner" packet, and the "outer" packet carrying the 95 tunneled inner packet is a UDP packet, which can pass through 96 firewalls and other middleboxes filtering that is a fact of life on 97 the current Internet. 99 Tunnel endpoints may be routers or middleboxes aggregating traffic 100 from a large number of tunnel users, therefore the computation of an 101 additional checksum on the outer UDP packet, may be seen as an 102 unwarranted burden on nodes that implement a tunneling protocol, 103 especially if the inner packet(s) are already protected by a 104 checksum. In IPv4, there is a checksum on the IP packet itself, and 105 the checksum on the outer UDP packet can be set to zero. However in 106 IPv6 there is not a checksum on the IP packet and RFC 2460 [RFC2460] 107 explicitly states that IPv6 receivers MUST discard UDP packets with a 108 zero checksum. So, while sending a UDP packet with a zero checksum 109 is permitted in IPv4 packets, it is explicitly forbidden in IPv6 110 packets. To improve support for IPv6 UDP tunnels, this document 111 updates RFC 2460 to allow tunnel endpoints to use a zero UDP checksum 112 under constrained situations (IPv6 tunnel transports that carry 113 checksum-protected packets), following the considerations in 114 [I-D.ietf-6man-udpzero]. 116 Unicast UDP Usage Guidelines for Application Designers [RFC5405] 117 should be consulted when reading this specification. It discusses 118 both UDP tunnels (Section 3.1.3) and the usage of Checksums (Section 119 3.4). 121 While the origin of this specification is the problem raised by the 122 draft titled "Automatic IP Multicast Without Explicit Tunnels", also 123 known as "AMT," [I-D.ietf-mboned-auto-multicast] we expect it to have 124 wide applicability. Since the first version of this document, the 125 need for an efficient UDP tunneling mechanism has increased. Other 126 IETF Working Groups, notably LISP [I-D.ietf-lisp] and Softwires 128 [RFC5619] have expressed a need to update the UDP checksum processing 129 in RFC 2460. We therefore expect this update to be applicable in 130 future to other tunneling protocols specified by these and other IETF 131 Working Groups. 133 2. Some Terminology 135 For the remainder of this document, we discuss only IPv6, since this 136 problem does not exist for IPv4. Therefore all reference to 'IP' 137 should be understood as a reference to IPv6. 139 The document uses the terms "tunneling" and "tunneled" as adjectives 140 when describing packets. When we refer to 'tunneling packets' we 141 refer to the outer packet header that provides the tunneling 142 function. When we refer to 'tunneled packets' we refer to the inner 143 packet, i.e., the packet being carried in the tunnel. 145 2.1. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 3. Problem Statement 153 This document provides an update for the case where a tunnel protocol 154 transports tunneled packets that already have a transport header with 155 a checksum. There is both a benefit and a cost to computing and 156 checking the UDP checksum of the outer (encapsulating) UDP transport 157 header. In certain cases, where reducing the forwarding cost is 158 important, such as for systems that perform the check in software, 159 the cost may outweigh the benefit; this document describes a means to 160 avoid that cost. In the case where there is an inner header with a 161 checksum. 163 4. Discussion 165 IPv6 UDP Checksum Considerations [I-D.ietf-6man-udpzero] describes 166 the issues related to allowing UDP over IPv6 to have a valid checksum 167 of zero and is not repeated here. 169 Section 5 and 6 of [I-D.ietf-6man-udpzero], identifies node and inner 170 protocol requirements respectively that introduce constraints on the 171 usage of a zero checksum for UDP over IPv6. This document is 172 intended to satisfy these requirements. 174 [I-D.ietf-6man-udpzero] and mailing list discussions have noted there 175 is still the possibility of deep-inspection firewall devices or other 176 middleboxes checking the UDP checksum field of the outer packet and 177 thereby discarding the tunneling packets. This would be an issue 178 also for any legacy IPv6 system that has not implemented this update 179 to the IPv6 specification. In this case, the system (according to 180 RFC 2460) will discard the zero-checksum UDP packets, and should log 181 this as an error. 183 The points below discuss how path errors can be detected and handled 184 in an UDP tunneling protocol when the checksum protection is 185 disabled. Note that other (non-tunneling) protocols may have 186 different approaches, but these are not the topic of this update. We 187 propose the following approach to handle this problem: 189 o Context (i.e. tunneling state) should be established via 190 application Protocol Data Units (PDUs) that are carried in 191 checksummed UDP packets. That is, any control packets flowing 192 between the tunnel endpoints should be protected by UDP checksums. 193 The control packets can also contain any negotiation required to 194 enable the endpoint/adapters to accept UDP packets with a zero 195 checksum. The control packets may also carry any negotiation 196 required to enable the endpoint/adapters to identify the set of 197 ports that need to enable reception of UDP datagrams with a zero 198 checksum. 200 o A system never sets the UDP checksum to zero in packets that do 201 not contain tunneled packets. 203 o UDP keep-alive packets with checksum zero can be sent to validate 204 paths, given that paths between tunnel endpoints can change and so 205 middleboxes in the path may vary during the life of the 206 association. Paths with middleboxes that are intolerant of a UDP 207 checksum of zero will drop the keep-alives and the endpoints will 208 discover that. Note that this need only be done per tunnel 209 endpoint pair, not per tunnel context. Keep-alive traffic can 210 include both packets with tunnel checksums and packets with 211 checksums equal to zero to enable the remote end to distinguish 212 between path failures and the blockage of packets with checksum 213 equal to zero. 215 o Corruption of the encapsulating IPv6 source address, destination 216 address and/or the UDP source port, and destination port fields : 217 If the restrictions in [I-D.ietf-6man-udpzero] are followed, the 218 inner packets (tunneled packets) will be protected and run the 219 usual (presumably small) risk of having undetected corruption(s). 220 If tunneling protocol contexts contain (at a minimum) source and 221 destination IP addresses and source and destination ports, there 222 are 16 possible corruption outcomes. We note that these outcomes 223 are not equally likely. The possible corruption outcomes may be: 225 * Half of the 16 possible corruption combinations have a 226 corrupted destination address. If the incorrect destination is 227 reached and the node doesn't have an application for the 228 destination port, the packet will be dropped. If the 229 application at the incorrect destination is the same tunneling 230 protocol and if it has a matching context (which can be assumed 231 to be a very low probability event) the inner packet will be 232 decapsulated and forwarded. Application developers can verify 233 the context of the packets they receive using UDP, as described 234 in [RFC5405]. Applications that verify the context of a 235 datagram are expected to have a high probability of discarding 236 corrupted data. [I-D.ietf-6man-udpzero] presents examples of 237 cases where corruption can inadvertently impact application 238 state. 240 * Half of the 8 possible corruption combinations with a correct 241 destination address have a corrupted source address. If the 242 tunnel contexts contain all elements of the address-port 243 4-tuple, then the likelihood is that this corruption will be 244 detected. It may in fact be discarded on route due to source 245 address validation techniques, such as Unicast Reverse Path 246 Forwarding [RFC2827]. 248 * Of the remaining 4 possibilities, with valid source and 249 destination IPv6 addresses, one has all 4 fields valid, the 250 other three have one or both ports corrupted. Again, if the 251 tunneling endpoint context contains sufficient information, 252 these errors should be detected with high probability. 254 o Corruption of source-fragmented encapsulating packets: In this 255 case, a tunneling protocol may reassemble fragments associated 256 with the wrong context at the right tunnel endpoint, or it may 257 reassemble fragments associated with a context at the wrong tunnel 258 endpoint, or corrupted fragments may be reassembled at the right 259 context at the right tunnel endpoint. In each of these cases, the 260 IPv6 length of the encapsulating header may be checked (though 261 [I-D.ietf-6man-udpzero] points out the weakness in this check). 262 In addition, if the encapsulated packet is protected by a 263 transport (or other) checksum, these errors can be detected (with 264 some probability). 266 While they do not guarantee correctness, these mechanism can reduce 267 the risks of relaxing the UDP checksum requirement for IPv6. 269 5. The Zero-Checksum Update 271 This specification updates IPv6 to allow a UDP checksum of zero for 272 the outer encapsulating packet of a tunneling protocol. UDP 273 endpoints that implement this update MUST change their behavior for 274 any destination port explicitly configured for zero checksum and MUST 275 NOT discard UDP packets received with a checksum value of zero on the 276 outer packet. When this is done, it requires the constraints in 277 Section 5 and 6 of [I-D.ietf-6man-udpzero]. 279 Specifically, the text in [RFC2460] Section 8.1, 4th bullet is 280 updated. We refer to the following text: 282 "Unlike IPv4, when UDP packets are originated by an IPv6 node, the 283 UDP checksum is not optional. That is, whenever originating a UDP 284 packet, an IPv6 node must compute a UDP checksum over the packet and 285 the pseudo-header, and, if that computation yields a result of zero, 286 it must be changed to hex FFFF for placement in the UDP header. IPv6 287 receivers must discard UDP packets containing a zero checksum, and 288 should log the error." 290 This item should be taken out of the bullet list and should be 291 replaced by: 293 Whenever originating a UDP packet, an IPv6 node SHOULD compute a 294 UDP checksum over the packet and the pseudo-header, and, if that 295 computation yields a result of zero, it must be changed to hex 296 FFFF for placement in the UDP header. IPv6 receivers SHOULD 297 discard UDP packets containing a zero checksum, and SHOULD log the 298 error. However, some protocols, such as tunneling protocols that 299 use UDP as a tunnel encapsulation, MAY omit computing the UDP 300 checksum of the encapsulating UDP header and set it to zero, 301 subject to the constraints described in Applicability Statement 302 for the use of IPv6 UDP Datagrams with Zero Checksums 303 [I-D.ietf-6man-udpzero]. In cases where the encapsulating 304 protocol uses a zero checksum for UDP, the receiver of packets 305 sent to a port enabled to receive zero-checksum packets MUST NOT 306 discard packets solely for having a UDP checksum of zero. Note 307 that these constraints apply only to encapsulating protocols that 308 omit calculating the UDP checksum and set it to zero. An 309 encapsulating protocol can always choose to compute the UDP 310 checksum, in which case, its behavior is not updated and uses the 311 method specified in Section 8.1 of RFC2460. 313 Middleboxes MUST allow IPv6 packets with UDP checksum equal to 314 zero to pass. Implementations of middleboxes MAY allow 315 configuration of specific port ranges for which a zero UDP 316 checksum is valid and may drop IPv6 UDP packets outside those 317 ranges. 319 The path between tunnel endpoints can change, thus also the 320 middleboxes in the path may vary during the life of the 321 association. Paths with middleboxes that are intolerant of a UDP 322 checksum of zero will drop any keep-alives sent to validate the 323 path using checksum zero and the endpoints will discover that. 324 Therefore keep-alive traffic SHOULD include both packets with 325 tunnel checksums and packets with checksums equal to zero to 326 enable the remote end to distinguish between path failures and the 327 blockage of packets with checksum equal to zero. Note that path 328 validation need only be done per tunnel endpoint pair, not per 329 tunnel context. 331 6. Additional Observations 333 The existence of this issue among a significant number of protocols 334 being developed in the IETF motivates this specified change. The 335 authors would also like to make the following observations: 337 o An empirically-based analysis of the probabilities of packet 338 corruptions (with or without checksums) has not (to our knowledge) 339 been conducted since about 2000. It is now 2012. We strongly 340 suggest that an empirical study is in order, along with an 341 extensive analysis of IPv6 header corruption probabilities. 343 o A key cause to the increased usage of UDP in tunneling is the lack 344 of protocol support in middleboxes. Specifically, new protocols, 345 such as LISP [I-D.ietf-lisp], prefer to use UDP tunnels to 346 traverse an end-to-end path successfully and avoid having their 347 packets dropped by middleboxes. If this were not the case, the 348 use of UDP-lite [RFC3828] might become more viable for some (but 349 not necessarily all) tunneling protocols. 351 o Another issue is that the UDP checksum is overloaded with the task 352 of protecting the IPv6 header for UDP flows (as is the TCP 353 checksum for TCP flows). Protocols that do not use a pseudo- 354 header approach to computing a checksum or CRC have essentially no 355 protection from mis-delivered packets. 357 7. IANA Considerations 359 This document makes no request of IANA. 361 Note to RFC Editor: this section may be removed on publication as an 362 RFC. 364 8. Security Considerations 366 It requires less work to generate zero-checksum attack packets than 367 ones with full UDP checksums. However, this does not lead to any 368 significant new vulnerabilities as checksums are not a security 369 measure and can be easily generated by any attacker. Properly 370 configured tunnels should check the validity of the inner packet and 371 perform any needed security checks, regardless of the checksum 372 status. Most attacks are generated from compromised hosts which 373 automatically create checksummed packets (in other words, it would 374 generally be more, not less, effort for most attackers to generate 375 zero UDP checksums on the host). 377 9. Acknowledgements 379 We would like to thank Brian Haberman and Gorry Fairhurst for 380 discussions and reviews. 382 10. References 384 10.1. Normative References 386 [I-D.ietf-6man-udpzero] 387 Fairhurst, G. and M. Westerlund, "Applicability Statement 388 for the use of IPv6 UDP Datagrams with Zero Checksums", 389 draft-ietf-6man-udpzero-07 (work in progress), 390 October 2012. 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 396 (IPv6) Specification", RFC 2460, December 1998. 398 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 399 G. Fairhurst, "The Lightweight User Datagram Protocol 400 (UDP-Lite)", RFC 3828, July 2004. 402 [RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent, 403 "Softwire Security Analysis and Requirements", RFC 5619, 404 August 2009. 406 10.2. Informative References 408 [I-D.ietf-lisp] 409 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 410 "Locator/ID Separation Protocol (LISP)", 411 draft-ietf-lisp-23 (work in progress), May 2012. 413 [I-D.ietf-mboned-auto-multicast] 414 Bumgardner, G., "Automatic Multicast Tunneling", 415 draft-ietf-mboned-auto-multicast-14 (work in progress), 416 June 2012. 418 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 419 Defeating Denial of Service Attacks which employ IP Source 420 Address Spoofing", BCP 38, RFC 2827, May 2000. 422 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 423 for Application Designers", BCP 145, RFC 5405, 424 November 2008. 426 Authors' Addresses 428 Marshall Eubanks 429 AmericaFree.TV LLC 430 P.O. Box 141 431 Clifton, Virginia 20124 432 USA 434 Phone: +1-703-501-4376 435 Fax: 436 Email: marshall.eubanks@gmail.com 438 P.F. Chimento 439 Johns Hopkins University Applied Physics Laboratory 440 11100 Johns Hopkins Road 441 Laurel, MD 20723 442 USA 444 Phone: +1-443-778-1743 445 Email: Philip.Chimento@jhuapl.edu 446 Magnus Westerlund 447 Ericsson 448 Farogatan 6 449 SE-164 80 Kista 450 Sweden 452 Phone: +46 10 714 82 87 453 Email: magnus.westerlund@ericsson.com