idnits 2.17.1 draft-denis-behave-nat-dccp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 398. 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 Copyright Line does not match the current year -- 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 (February 17, 2008) is 5910 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-behave-nat-icmp-07 == Outdated reference: A later version (-08) exists of draft-ietf-behave-tcp-07 == Outdated reference: A later version (-03) exists of draft-phelan-dccp-natencap-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behavior Engineering for Hindrance R. Denis-Courmont 3 Avoidance (if taken) VideoLAN project 4 Internet-Draft February 17, 2008 5 Intended status: Standards Track 6 Expires: August 20, 2008 8 Network Address Translation (NAT) Behavioral Requirements for DCCP 9 draft-denis-behave-nat-dccp-01.txt 11 Status of This Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 20, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document defines a set of requirements for NATs that handle 43 DCCP. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 3 50 4. DCCP Connection Initiation . . . . . . . . . . . . . . . . . . 4 51 5. NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . . 5 52 6. Application Level Gateways . . . . . . . . . . . . . . . . . . 5 53 7. Other Requirements Applicable to DCCP . . . . . . . . . . . . . 6 54 8. DCCP without NAT support . . . . . . . . . . . . . . . . . . . 6 55 9. DCCP simultaneous open . . . . . . . . . . . . . . . . . . . . 7 56 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 57 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 58 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 59 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 13.1. Normative References . . . . . . . . . . . . . . . . . . . 7 61 13.2. Informative References . . . . . . . . . . . . . . . . . . 8 63 1. Introduction 65 For historical reasons, NAT devices are not typically capable of 66 handling datagrams and flows for application using the Datagram 67 Congestion Control Protocol (DCCP)[RFC4340]. 69 This draft discusses the technical issues involved, and proposes a 70 set of requirements for NAT devices to handle DCCP in a way that 71 enables when either or both of the DCCP endpoints are located behind 72 one or more NAT devices. All definitions and requirements in 73 [RFC4787] are inherited here. The requirements are otherwise 74 designed similarly to those in [I-D.ietf-behave-tcp], from which this 75 memo borrows its structure and much of its content. 77 Note however that, if both endpoints are hindered by NAT devices, the 78 normal model of asymmetric connection model of DCCP will not work. A 79 simultaneous open must be performed, as in 80 [I-D.fairhurst-dccp-behave-update]. Also, a separate unspecified 81 mechanism may be needed, such as UNSAF protocols, if an endpoint 82 needs to learn its own external NAT mappings. 84 2. Definitions 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 This documentation uses the term "DCCP connection" to refer to 91 invidual DCCP flows, as uniquely identified by the the 4-tuple 92 (source and destination IP addresses and DCCP ports) at a given time. 94 This document uses the term "NAT mapping" to refer to state at the 95 NAT necessary for network address and port translation of DCCP 96 connections. This document also uses the terms "endpoint independent 97 mapping", "address dependent mapping", "address and port dependent 98 mapping", "filtering behavior", "endpoint independent filtering", 99 "address dependent filtering", "address and port dependent 100 filtering", "port assignment", "port overloading", "hairpinning", and 101 "external source IP address and port" as defined in [RFC4787]. 103 3. Applicability statement 105 This document applies to NAT devices that want to handle DCCP 106 datagrams. It is not the intent of this document to deprecate the 107 overwhelming majority of deployed NAT devices. These NATs are simply 108 not expected to handle DCCP, so this memo is not applicable to them. 110 Expected NAT behaviors applicable to DCCP connections are very 111 similar to those applicable to TCP connections (with the exception or 112 REQ-6 below). The following requirements are discussed and justified 113 extensively in [I-D.ietf-behave-tcp]. These justifications are not 114 reproduced here for the sake of brevity. 116 In addition to the usual changes to the IP header (in particular the 117 IP addresses), NAT devices need to mangle: 118 o the DCCP source port, for outgoing packets, depending on the NAT 119 mapping 120 o the DCCP destination port, for incoming packets, depending on the 121 NAT mapping 122 o the DCCP checksum, to compensate for IP address and port number 123 modifications. 125 Because changing the the source or destination IP address of a DCCP 126 packet will normally invalidate the DCCP checksum, it is not possible 127 to use DCCP through a NAT without dedicated support. Some NAT 128 devices are known to provide a "generic" transport protocol support, 129 whereby only the IP header is mangled. That scheme is not sufficient 130 to support DCCP in any case. 132 4. DCCP Connection Initiation 134 4.1. Address and Port Mapping Behavior 136 A NAT uses a mapping to translate packets for each DCCP connection. 137 A mapping is dynamically allocated for connections initiated from the 138 internal side, and potentially reused for certain subsequent 139 connections. NAT behavior regarding when a mapping can be reused 140 differs for different NATs as described in [RFC4787]. 142 REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior for 143 DCCP. 145 4.2. Internally Initiated Connections 147 FIXME/TBD: may change as DCCP simultaneous open progresses. 149 REQ-2: A NAT MUST support all valid sequences of DCCP packets 150 (defined in [RFC4340] and its updates) for connections initiated both 151 internally as well as externally when the connection is permitted by 152 the NAT. 154 In particular, in addition to handling the DCCP 3-way handshake mode 155 of connection initiation, A NAT MUST handle the DCCP simultaneous- 156 open mode of connection initiation (FIXME: currently work-in-progress 157 in the DCCP working group). 159 4.3. Externally Initiated Connections 161 REQ-3: If application transparency is most important, it is 162 RECOMMENDED that a NAT have an "Endpoint independent filtering" 163 behavior for DCCP. If a more stringent filtering behavior is most 164 important, it is RECOMMENDED that a NAT have an "Address dependent 165 filtering" behavior. 166 o The filtering behavior MAY be an option configurable by the 167 administrator of the NAT. 168 o The filtering behavior for TCP MAY be independent of thefiltering 169 behavior for UDP. 171 REQ-4: A NAT MUST NOT respond to an unsolicited inbound DCCP-Request 172 (TBD: add stuff for DCCP simultaneous open) packet for at least 6 173 seconds after the packet is received. If during this interval the 174 NAT receives and translates an outbound DCCP packet (TBD: DCCP packet 175 type) for the connection the NAT MUST silently drop the original 176 unsolicited inbound DCCP-Request packet. Otherwise the NAT SHOULD 177 send an ICMP Port Unreachable error (Type 3, Code 3) for the original 178 DCCP-Request, unless the security policy forbids it. 180 5. NAT Session Refresh 182 The "established connection idle-timeout" for a NAT is defined as the 183 minimum time a DCCP connection in the established phase must remain 184 idle before the NAT considers the associated session a candidate for 185 removal. The "transitory connection idle-timeout" for a NAT is 186 defined as the minimum time a DCCP connection in the CLOSEREQ or 187 CLOSING phases must remain idle before the NAT considers the 188 associated session a candidate for removal. DCCP connections in the 189 TIMEWAIT state are not affected by the "transitory connection idle- 190 timeout". 192 REQ-5: If a NAT cannot determine whether the endpoints of a DCCP 193 connection are active, it MAY abandon the session if it has been idle 194 for some time. In such cases, the value of the "established 195 connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. 196 The value of the "transitory connection idle-timeout" MUST NOT be 197 less than 4 minutes. The value of the NAT idle-timeouts MAY be 198 configurable. 200 NAT behavior for handling DCCP-Reset packets, or connections in 201 TIMEWAIT state is left unspecified. 203 6. Application Level Gateways 205 Contraty to TCP, DCCP is a loss-tolerant protocol. Therefore, 206 modifying the payload of DCCP packets present a significant 207 additionnal challenge in maintaining sane DCCP sequence numbers, if 208 the size of the payload were altered. Also, there are no known DCCP- 209 capable Application Level Gateways (ALGs) at the time of writing this 210 document. 212 REQ-6: If a NAT includes ALGs, it MUST NOT affect DCCP. 214 NOTE: This is not consistent with REQ-6 of [I-D.ietf-behave-tcp]. 216 7. Other Requirements Applicable to DCCP 218 A list of general and UDP specific NAT behavioral requirements are 219 described in [RFC4787]. A list of ICMP specific NAT behavioral 220 requirements are described in [I-D.ietf-behave-nat-icmp]. The 221 requirements listed below reiterate the requirements from these two 222 documents that directly affect DCCP. The following requirements do 223 not relax anyrequirements in [RFC4787] or [I-D.ietf-behave-nat-icmp]. 225 7.1. Port Assignment 227 REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port 228 overloading" for DCCP. 230 7.2. Hairpinning Behavior 232 REQ-8: A NAT MUST support "Hairpinning" for DCCP. Futhermore, A 233 NAT's Hairpinning behavior MUST be of type "External source IP 234 address and port". 236 7.3. ICMP Responses to DCCP Packets 238 REQ-9: If a NAT translates DCCP, it SHOULD translate ICMP Destination 239 Unreachable (Type 3) messages. 241 REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the 242 NAT mapping or DCCP connection for which the ICMP was generated. 244 8. DCCP without NAT support 246 If the NAT device cannot be updated to support DCCP, DCCP datagram 247 could be encapsulated within an additionnal UDP transport header. 248 Indeed, most NAT devices are already capable of handling UDP. 250 There are significant disadvantages to this approach: 251 o Both sides of the DCCP session need must be updated to use 252 tunnelling, even though only one side might be hindered with a 253 NAT. 255 o A method MUST be defined to negociate when to use tunnelling. 256 o The per-packet overhead is increased. 258 A DCCP transport-specific solution is specified by 259 [I-D.phelan-dccp-natencap]. Alternatively, existing IP tunneling 260 protocols, such as ESP-in-UDP[RFC3948] (especially with the NULL 261 cipher suite) or Teredo[RFC4380], could be used. 263 9. DCCP simultaneous open 265 When both parties to an intended DCCP session are located behind 266 either a NAT device or a stateful firewall, neither can act as the 267 paassive endpoint in the connection establishment. 269 Unfortunately, at the time of writing, the DCCP connection state 270 machine does not allow both peers to behave as active endpoint, as is 271 the case in TCP simultaneous open. It is expected that this issue 272 will be tackled in the DCCP working group shortly (TODO: reference 273 relevant I-D). 275 10. Security Considerations 277 TBD. 279 11. IANA Considerations 281 This document raises no IANA considerations. 283 12. Acknowledgments 285 The author would like to thank ... for their comments on this 286 document. 288 This memo borrows heavily from draft-ietf-behave-tcp-07, by S. Guha 289 (editor), K. Biswas, B. Ford, S. Sivakumar and P. Srisuresh. 291 13. References 293 13.1. Normative References 295 [I-D.ietf-behave-nat-icmp] Srisuresh, P., Ford, B., 296 Sivakumar, S., and S. Guha, "NAT 297 Behavioral Requirements for ICMP 298 protocol", 299 draft-ietf-behave-nat-icmp-07 300 (work in progress), 301 February 2008. 303 [RFC2119] Bradner, S., "Key words for use 304 in RFCs to Indicate Requirement 305 Levels", BCP 14, RFC 2119, 306 March 1997. 308 [RFC4340] Kohler, E., Handley, M., and S. 309 Floyd, "Datagram Congestion 310 Control Protocol (DCCP)", 311 RFC 4340, March 2006. 313 [RFC4787] Audet, F. and C. Jennings, 314 "Network Address Translation 315 (NAT) Behavioral Requirements for 316 Unicast UDP", BCP 127, RFC 4787, 317 January 2007. 319 13.2. Informative References 321 [I-D.fairhurst-dccp-behave-update] Fairhurst, G. and G. Renker, "An 322 Update for DCCP Connection 323 Establishment to Assist NAT & 324 Firewall Traversal", draft- 325 fairhurst-dccp-behave-update-01 326 (work in progress), 327 November 2007. 329 [I-D.ietf-behave-tcp] Guha, S., "NAT Behavioral 330 Requirements for TCP", 331 draft-ietf-behave-tcp-07 (work in 332 progress), April 2007. 334 [I-D.phelan-dccp-natencap] Phelan, T., "Datagram Congestion 335 Control Protocol (DCCP) 336 Encapsulation for NAT Traversal 337 (DCCP-NAT)", 338 draft-phelan-dccp-natencap-00 339 (work in progress), 340 February 2008. 342 [RFC3948] Huttunen, A., Swander, B., Volpe, 343 V., DiBurro, L., and M. Stenberg, 344 "UDP Encapsulation of IPsec ESP 345 Packets", RFC 3948, January 2005. 347 [RFC4380] Huitema, C., "Teredo: Tunneling 348 IPv6 over UDP through Network 349 Address Translations (NATs)", 350 RFC 4380, February 2006. 352 Author's Address 354 Remi Denis-Courmont 355 VideoLAN project 357 EMail: rem@videolan.org 358 URI: http://www.videolan.org/ 360 Full Copyright Statement 362 Copyright (C) The IETF Trust (2008). 364 This document is subject to the rights, licenses and restrictions 365 contained in BCP 78, and except as set forth therein, the authors 366 retain all their rights. 368 This document and the information contained herein are provided on an 369 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 370 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 371 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 372 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 373 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 374 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 376 Intellectual Property 378 The IETF takes no position regarding the validity or scope of any 379 Intellectual Property Rights or other rights that might be claimed to 380 pertain to the implementation or use of the technology described in 381 this document or the extent to which any license under such rights 382 might or might not be available; nor does it represent that it has 383 made any independent effort to identify any such rights. Information 384 on the procedures with respect to rights in RFC documents can be 385 found in BCP 78 and BCP 79. 387 Copies of IPR disclosures made to the IETF Secretariat and any 388 assurances of licenses to be made available, or the result of an 389 attempt made to obtain a general license or permission for the use of 390 such proprietary rights by implementers or users of this 391 specification can be obtained from the IETF on-line IPR repository at 392 http://www.ietf.org/ipr. 394 The IETF invites any interested party to bring to its attention any 395 copyrights, patents or patent applications, or other proprietary 396 rights that may cover technology that may be required to implement 397 this standard. Please address the information to the IETF at 398 ietf-ipr@ietf.org. 400 Acknowledgement 402 Funding for the RFC Editor function is provided by the IETF 403 Administrative Support Activity (IASA).