idnits 2.17.1 draft-amend-tsvwg-dccp-udp-header-conversion-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 -- The document date (March 11, 2019) is 1873 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC768' is mentioned on line 376, but not defined == Unused Reference: 'RFC0768' is defined on line 401, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group M. Amend 3 Internet-Draft Deutsche Telekom 4 Intended status: Experimental A. Brunstrom 5 Expires: September 12, 2019 A. Kassler 6 Karlstad University 7 V. Rakocevic 8 City University of London 9 March 11, 2019 11 Lossless and overhead free DCCP - UDP header conversion (U-DCCP) 12 draft-amend-tsvwg-dccp-udp-header-conversion-00 14 Abstract 16 The Datagram Congestion Control protocol (DCCP) is a non-widely 17 deployed transport protocol in the Internet. The reason for that is 18 a typical chicken-egg problem. Even if there would be a use for 19 application developer to rely on DCCP, middle-boxes like firewalls 20 and NATs will prevent DCCP end-to-end since they lack support for 21 DCCP. However, as long as the protocol penetration of DCCP will not 22 increase, middle-boxes will not handle DCCP properly. To overcome 23 this challenge NAT/NATP traversal and UDP encapsulation for DCCP is 24 already defined. However the first requires special middle-box 25 support and the latter introduces overhead. The proposal of a 26 multipath extension for DCCP further stresses the question of 27 efficient middle-box passing as its main goal is to be applied over 28 the Internet, traversing numerous uncontrolled middle-boxes. This 29 document introduces a new approach, disguising DCCP during 30 transmission as UDP without requiring middle-box modification nor 31 introducing any overhead. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 12, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. U-DCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3.2. The DCCP Generic header . . . . . . . . . . . . . . . . . 4 72 3.3. UDP header . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.4. U-DCCP conversion considerations . . . . . . . . . . . . 6 74 3.5. U-DCCP header . . . . . . . . . . . . . . . . . . . . . . 6 75 3.6. Implementation . . . . . . . . . . . . . . . . . . . . . 7 76 3.7. Pseudo-code DCCP to U-DCCP conversion . . . . . . . . . . 7 77 3.8. Pseudo-code U-DCCP to DCCP restoration . . . . . . . . . 8 78 3.9. U-DCCP negotiation (required????) . . . . . . . . . . . . 9 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 6. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 83 8. Informative References . . . . . . . . . . . . . . . . . . . 9 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a 89 transport-layer protocol that provides upper layers with the ability 90 to use non-reliable congestion-controlled flows. The current 91 specification for DCCP [RFC4340] specifies a direct native 92 encapsulation in IPv4 or IPv6 packets. 94 DCCP support has been specified for devices that use Network Address 95 Translation (NAT) or Network Address and Port Translation (NAPT) 96 [RFC5597]. However, there is a significant installed base of NAT/ 97 NAPT devices that do not support [RFC5597]. An UDP encapsulation for 98 DCCP [RFC6773] circumvents such limitations and makes DCCP compatible 99 with any UDP [RFC768] compliant device that support [RFC4787] but do 100 not support [RFC5597]. For convenience, the standard encapsulation 101 for DCCP [RFC4340] (including [RFC5596] and [RFC5597] as required) is 102 referred to as DCCP-STD, whereas the UDP encapsulation for DCCP 103 [RFC6773] is referred to as DCCP-UDP. 105 It can be stated, that DCCP-STD and DCCP-UDP are techniques, which 106 increases the success rate of DCCP transmissions significantly. 107 However, DCCP-STD fails on devices that blocks DCCP for any reasons. 108 On the other hand, DCCP-UDP uses the well-accepted UDP to let devices 109 assume they handle the UDP protocol, but for the cost of a reduced 110 goodput/throughput ratio. 112 To compensate the inefficiency of DCCP-STD (device blocking) and 113 DCCP-UDP (overhead), this document proposes a beneficial modification 114 scheme relying like DCCP-UDP on UDP, but for no overhead. This goal 115 is reached by re-arranging DCCP's extended header in that it looks 116 like UDP, without losing critical information and is referred to as 117 U-DCCP. 119 U-DCCP is limited to DCCP's extended header, requiring X is set to 1. 120 Otherwise U-DCCP relies on the NAT/NATP functionalities specified for 121 UDP in [RFC4787], [RFC6888] and [RFC7857]. 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 3. U-DCCP 131 3.1. Overview 133 The basic approach of U-DCCP is to modify the extended header of a 134 DCCP packet such that it appears like UDP [RFC768]. In particular, 135 this takes place without losing information, but requires a U-DCCP 136 termination before the packet is delivered to the DCCP end system 137 (!!! Auto-detection via e.g. SDP required??? !!!). The method does 138 not change the 4-tuple of IP and port addressing, however it changes 139 the protocol carried over IP to UDP. In consequence, the length of 140 the packet remains unchanged and behaves like DCCP-STD. The solution 141 is not a tunneling approach. It requires that the same port as for 142 DCCP can be used by UDP. 144 The method is designed to support use when these addresses are 145 modified by a device that implements NAT/NAPT. A NAT translates the 146 IP addresses, which impacts the transport-layer checksum. A NAPT 147 device may also translate the port values (usually the source port). 148 In both cases, the outer transport header that includes these values 149 would need to be updated by the NAT/NAPT. 151 U-DCCP supports IPv4 and IPv6. 153 The basic format of a U-DCCP packet is: 155 +-----------------------------------+ 156 | IP Header (IPv4 or IPv6) | Variable length 157 +-----------------------------------+ 158 |UDP like arranged DCCP ext. Header | 8 bytes \ 159 +-----------------------------------+ ) U-DCCP header 160 |Rest of rearranged DCCP ext. Header| 8 bytes / 161 +-----------------------------------+ 162 | Additional (type-specific) Fields | Variable length (could be 0) 163 +-----------------------------------+ 164 | DCCP Options | Variable length (could be 0) 165 +-----------------------------------+ 166 | Application Data Area | Variable length (could be 0) 167 +-----------------------------------+ 169 Figure 1: Format of U-DCCP packet 171 The U-DCCP header is described in Section 3.4 after introducing the 172 traditional DCCP header in Section 3.1 and its target appearance of a 173 UDP header in Section 3.2. Section 3.3 discusses considerations for 174 building the U-DCCP header upfront. 176 3.2. The DCCP Generic header 178 The DCCP Generic Header [RFC4340] takes two forms, one with long 179 sequence numbers (48 bits) and the other with short sequence numbers 180 (24 bits), which is not part of U-DCCP's modification. 182 0 1 2 3 183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Source Port | Dest Port | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Data Offset | CCVal | CsCov | Checksum | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | |X| | . 190 | Res | Type |=| Reserved | Sequence Number (high bits) . 191 | | |1| | . 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Sequence Number (low bits) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 2: The extended DCCP Header with Long Sequence Numbers 197 [RFC4340] 199 0 1 2 3 200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Source Port | Dest Port | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Data Offset | CCVal | CsCov | Checksum | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | | |X| | 207 | Res | Type |=| Sequence Number (low bits) | 208 | | |0| | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Figure 3: The short DCCP Header with Short Sequence Numbers [RFC4340] 213 All generic header fields have the meaning specified in [RFC4340], 214 updated by [RFC5596]. 216 3.3. UDP header 218 0 1 2 3 219 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Source Port | Dest Port | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Length | Checksum | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 4: The UDP Header [RFC768] 228 All header fields have the meaning specified in [RFC768]. 230 3.4. U-DCCP conversion considerations 232 The U-DCCP header has the goal to merge the information of DCCP's 233 extended header (Section 3.1) and imitates in the beginning the UDP 234 header (Section 3.2). Information, to restore a DCCP header from any 235 conversion, which must not be lost are source and destination port, 236 Data Offset, CCVal, CsCov, Checksum, Type, X and the Sequence Number. 238 Compared with the UDP header, the DCCP ext. header shows similarities 239 in source and destination port and checksum. The length field of UDP 240 (bits 33-48) is not part of the DCCP header and contains in case of 241 DCCP the fields Data Offset, CCVal and CsCov. 243 For the goal of imitating UDP, the checksum must cover the whole 244 datagram, which renders any limitation by CsCov useless. The 245 checksum itself is required to re-calculate after conversion anyway. 247 If the conversion is limited to DCCP'S extended header only, X is 248 always "1". 250 Thus, Data Offset, CCVal, Type and Sequence Number must be re- 251 arranged in a way that the Length field of UDP can be applied. 253 3.5. U-DCCP header 255 The considerations of Section 3.3 leads to the following header, 256 denoted as U-DCCP header. 258 0 1 2 3 259 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 U | Source Port | Dest Port | 262 D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 P | Length | Checksum | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type | CCVal | Data Offset | Sequence Number (high bits) . 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 . Sequence Number (low bits) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 5: The U-DCCDP Header 272 The first 8 bytes of the U-DCCP header corresponds to [RFC768] and 273 the fields are interpreted as follows: 275 Source and Dest(ination) Ports: 16 bits each 277 These fields identify the UDP ports on which the source and 278 destination (respectively) of the packet are listening for incoming 279 UDP packets. The UDP port values do identify the DCCP source and 280 destination ports. 282 Length: 16 bits 284 This field is the length of the UDP datagram, including the UDP 285 header and the payload (for U-DCCP, the payload comprises the payload 286 of the original DCCP datagram and part of its header). 288 Checksum: 16 bits 290 This field is the Internet checksum of a network-layer pseudoheader 291 and Length bytes of the UDP packet [RFC768]. The UDP checksum MUST 292 NOT be zero for a U-DCCP packet. 294 The remaining 8 bytes of the U-DCCP header contains: 296 Type, CCVal, Data Offset, Seq. Number: As specified in [RFC4340] 298 In case U-DCCP is applied, the IP network layer must be instructed to 299 carry an UDP datagram and its checksum must be re-calculated, for 300 detailed information see section 4. 302 3.6. Implementation 304 The process of applying U-DCCP behaves as follows and requires: 306 DCCP generation -> U-DCCP conversion -> UDP transmission -> U-DCCP 307 reception and restoration -> DCCP reception 309 The conversion can be integrated into DCCP endpoints directly or as 310 an additional component on the way along the transmission route. 311 Depending on the degree of integration, especially the process of 312 checksum calculation and validation can be optimized. Section 4.1 313 and 4.2 provides a possible pseudo-code for the conversion without 314 any optimized integration into the sender's network stack nor in the 315 receiver's network stack. The pseudo-code assumes explicit knowledge 316 about which U-DCCP flows need conversion between sender and receiver. 318 3.7. Pseudo-code DCCP to U-DCCP conversion 320 A possible processing of an already generated DCCP datagram for 321 U-DCCP conversion: 323 1. Receive DCCP datagram. 325 2. Check eligibility for conversion otherwise bypass conversion. 327 3. Verify consistency, e.g. checksum otherwise drop. 329 4. Shift Type and CCVal field to the ninth octet. 331 5. Shift Data Offset field to the tenth octet. 333 6. Place a length information at octet 5+6 corresponding to 334 [RFC768]. 336 7. Modify the IP header's encapsulated protocol from DCCP to UDP. 338 8. Re-calculate IP header checksum. 340 9. Reset DCCP checksum field: octet 7+8 = 0. 342 10. Generate new checksum at octet 7+8 as described in [RFC768]. 344 11. Forward to destination based on the unmodified 4-tuple of IP- 345 addresses and ports. 347 3.8. Pseudo-code U-DCCP to DCCP restoration 349 A possible processing of an already converted U-DCCP datagram for 350 DCCP restoration: 352 1. Receive UDP datagram. 354 2. Check eligibility for restoration otherwise bypass restoration 356 3. Validate UDP checksum otherwise drop. 358 4. Restore Data Offset field according to [RFC4340]. 360 5. Restore CCVal field according to [RFC4340]. 362 6. Set CsCov field according to [RFC4340] to "0". 364 7. Restore Type field according to [RFC4340]. 366 8. Set Reserved bits according to [RFC4340] to "0". 368 9. Set X according to [RFC4340] to "1". 370 10. Modify the IP header's encapsulated protocol from UDP to DCCP. 372 11. Re-calculate IP header checksum. 374 12. Reset DCCP checksum field: octet 7+8 = 0. 376 13. Generate new checksum at octet 7+8 as described in [RFC768]. 378 14. Forward to destination based on the unmodified 4-tuple of IP- 379 addresses and ports. 381 3.9. U-DCCP negotiation (required????) 383 Tbd later if required. Otherwise assumes explicit knowledge about 384 the U-DCCP conversion between sender and receiver. 386 4. Security Considerations 388 TBD. 390 5. IANA Considerations 392 6. Notes 394 This document is inspired by [RFC6773] and some text passages for the 395 -00 version are copied unmodified. 397 7. Acknowledgments 399 8. Informative References 401 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 402 DOI 10.17487/RFC0768, August 1980, 403 . 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, 407 DOI 10.17487/RFC2119, March 1997, 408 . 410 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 411 Congestion Control Protocol (DCCP)", RFC 4340, 412 DOI 10.17487/RFC4340, March 2006, 413 . 415 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 416 Translation (NAT) Behavioral Requirements for Unicast 417 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 418 2007, . 420 [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol 421 (DCCP) Simultaneous-Open Technique to Facilitate NAT/ 422 Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596, 423 September 2009, . 425 [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) 426 Behavioral Requirements for the Datagram Congestion 427 Control Protocol", BCP 150, RFC 5597, 428 DOI 10.17487/RFC5597, September 2009, 429 . 431 [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A 432 Datagram Congestion Control Protocol UDP Encapsulation for 433 NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 434 2012, . 436 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 437 A., and H. Ashida, "Common Requirements for Carrier-Grade 438 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 439 April 2013, . 441 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, 442 S., and K. Naito, "Updates to Network Address Translation 443 (NAT) Behavioral Requirements", BCP 127, RFC 7857, 444 DOI 10.17487/RFC7857, April 2016, 445 . 447 Authors' Addresses 449 Markus Amend 450 Deutsche Telekom 451 T-Online-Allee 1 452 Darmstadt 453 Germany 455 Email: Markus.Amend@telekom.de 457 Anna Brunstrom 458 Karlstad University 459 Universitetsgatan 2 460 651 88 Karlstad 461 Sweden 463 Email: anna.brunstrom@kau.se 464 Andreas Kassler 465 Karlstad University 466 Universitetsgatan 2 467 651 88 Karlstad 468 Sweden 470 Email: andreas.kassler@kau.se 472 Veselin Rakocevic 473 City University of London 474 Northampton Square 475 London 476 United Kingdom 478 Email: veselin.rakocevic.1@city.ac.uk