idnits 2.17.1 draft-ietf-behave-dccp-03.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 412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 423. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 430. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 436. 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 (October 04, 2008) is 5655 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-09 == Outdated reference: A later version (-08) exists of draft-ietf-dccp-simul-open-04 == Outdated reference: A later version (-11) exists of draft-ietf-dccp-serv-codes-08 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 VideoLAN project 4 Internet-Draft October 04, 2008 5 Intended status: Standards Track 6 Expires: April 7, 2009 8 Network Address Translation (NAT) Behavioral Requirements for DCCP 9 draft-ietf-behave-dccp-03.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 April 7, 2009. 36 Abstract 38 This document defines a set of requirements for NATs handling the 39 Datagram Congestion Control Protocol (DCCP). Those allow DCCP 40 applications, such as streaming applications to operate consistently. 41 These requirements are very similar to the TCP requirements for NATs 42 already published by the IETF Behavior Engineering for Hindrance 43 Avoidance (BEHAVE) working group. Developing NATs that meet this set 44 of requirements will greatly increase the likelihood that 45 applications using DCCP will function properly. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 3 52 4. DCCP Connection Initiation . . . . . . . . . . . . . . . . . . 4 53 5. NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . . 5 54 6. Application Level Gateways . . . . . . . . . . . . . . . . . . 6 55 7. Other Requirements Applicable to DCCP . . . . . . . . . . . . . 6 56 8. Requirements specific to DCCP . . . . . . . . . . . . . . . . . 7 57 9. DCCP without NAT support . . . . . . . . . . . . . . . . . . . 7 58 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 59 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 60 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 61 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 13.1. Normative References . . . . . . . . . . . . . . . . . . . 9 63 13.2. Informative References . . . . . . . . . . . . . . . . . . 9 65 1. Introduction 67 For historical reasons, NAT devices are not typically capable of 68 handling datagrams and flows for applications using the Datagram 69 Congestion Control Protocol (DCCP)[RFC4340]. 71 This draft discusses the technical issues involved, and proposes a 72 set of requirements for NAT devices to handle DCCP in a way that 73 enables communications when either or both of the DCCP endpoints are 74 located behind one or more NAT devices. All definitions and 75 requirements in [RFC4787] are inherited here. The requirements are 76 otherwise designed similarly to those in [I-D.ietf-behave-tcp], from 77 which this memo borrows its structure and much of its content. 79 Note however that, if both endpoints are hindered by NAT devices, the 80 normal model of asymmetric connection model of DCCP will not work. A 81 simultaneous open must be performed, as in 82 [I-D.ietf-dccp-simul-open]. Also, a separate unspecified mechanism 83 may be needed, such as Unilateral Self Address Fixing 84 (UNSAF)[RFC3424] protocols, if an endpoint needs to learn its own 85 external NAT mappings. 87 2. Definitions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 This documentation uses the term "DCCP connection" to refer to 94 invidual DCCP flows, as uniquely identified by the quadruple (source 95 and destination IP addresses and DCCP ports) at a given time. 97 This document uses the term "NAT mapping" to refer to state at the 98 NAT necessary for network address and port translation of DCCP 99 connections. This document also uses the terms "endpoint-independent 100 mapping", "address-dependent mapping", "address and port-dependent 101 mapping", "filtering behavior", "endpoint-independent filtering", 102 "address-dependent filtering", "address and port-dependent 103 filtering", "port assignment", "port overloading", "hairpinning", and 104 "external source IP address and port" as defined in [RFC4787]. 106 3. Applicability statement 108 This document applies to NAT devices that want to handle DCCP 109 datagrams. It is not the intent of this document to deprecate the 110 overwhelming majority of deployed NAT devices. These NATs are simply 111 not expected to handle DCCP, so this memo is not applicable to them. 113 Expected NAT behaviors applicable to DCCP connections are very 114 similar to those applicable to TCP connections (with the exception of 115 REQ-6 below). The following requirements are discussed and justified 116 extensively in [I-D.ietf-behave-tcp]. These justifications are not 117 reproduced here for the sake of brevity. 119 In addition to the usual changes to the IP header (in particular the 120 IP addresses), NAT devices need to mangle: 122 o the DCCP source port, for outgoing packets, depending on the NAT 123 mapping 125 o the DCCP destination port, for incoming packets, depending on the 126 NAT mapping 128 o the DCCP checksum, to compensate for IP address and port number 129 modifications. 131 Because changing the source or destination IP address of a DCCP 132 packet will normally invalidate the DCCP checksum, it is not possible 133 to use DCCP through a NAT without dedicated support. Some NAT 134 devices are known to provide a "generic" transport protocol support, 135 whereby only the IP header is mangled. That scheme is not sufficient 136 to support DCCP. 138 4. DCCP Connection Initiation 140 4.1. Address and Port Mapping Behavior 142 A NAT uses a mapping to translate packets for each DCCP connection. 143 A mapping is dynamically allocated for connections initiated from the 144 internal side, and potentially reused for certain subsequent 145 connections. NAT behavior regarding when a mapping can be reused 146 differs for different NATs as described in [RFC4787]. 148 REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior for 149 DCCP. 151 4.2. Established Connections 153 REQ-2: A NAT MUST support all valid sequences of DCCP packets 154 (defined in [RFC4340] and its updates) for connections initiated both 155 internally as well as externally when the connection is permitted by 156 the NAT. In particular, in addition to handling the DCCP 3-way 157 handshake mode of connection initiation, A NAT MUST handle the DCCP 158 simultaneous-open mode of connection initiation, defined in 159 [I-D.ietf-dccp-simul-open]. That mode updates DCCP by adding a new 160 packet type, DCCP-Listen. The A DCCP-Listen packet communicates the 161 information necessary to uniquely identify a DCCP session. NATs may 162 utilise the connection information (address, port, Service Code) to 163 establish local forwarding state. 165 4.3. Externally Initiated Connections 167 REQ-3: If application transparency is most important, it is 168 RECOMMENDED that a NAT have an "Endpoint-independent filtering" 169 behavior for DCCP. If a more stringent filtering behavior is most 170 important, it is RECOMMENDED that a NAT have an "Address-dependent 171 filtering" behavior. 173 o The filtering behavior MAY be an option configurable by the 174 administrator of the NAT. 176 o The filtering behavior for DCCP MAY be independent of the 177 filtering behavior for any other transport-layer protocol, such as 178 UDP, UDP-Lite, TCP, SCTP. 180 REQ-4: A NAT MUST wait for at least 6 seconds from the reception of 181 an unsolicited inbound DCCP-Listen or DCCP-Sync packet before it may 182 respond with an ICMP Port Unreachable error, an ICMP Protocol 183 Unreachable error or a DCCP-Reset. If during this interval the NAT 184 receives and translates an outbound DCCP-Request packet for the 185 connection the NAT MUST silently drop the original unsolicited 186 inbound DCCP-Listen packet. Otherwise the NAT SHOULD send an ICMP 187 Port Unreachable error (Type 3, Code 3) for the original DCCP-Listen, 188 unless the security policy forbids it. 190 5. NAT Session Refresh 192 The "established connection idle-timeout" for a NAT is defined as the 193 minimum time a DCCP connection in the established phase must remain 194 idle before the NAT considers the associated session a candidate for 195 removal. The "transitory connection idle-timeout" for a NAT is 196 defined as the minimum time a DCCP connection in the CLOSEREQ or 197 CLOSING phases must remain idle before the NAT considers the 198 associated session a candidate for removal. DCCP connections in the 199 TIMEWAIT state are not affected by the "transitory connection idle- 200 timeout". 202 REQ-5: If a NAT cannot determine whether the endpoints of a DCCP 203 connection are active, it MAY abandon the session if it has been idle 204 for some time. In such cases, the value of the "established 205 connection idle-timeout" MUST be of 124 minutes or longer. The value 206 of the "transitory connection idle-timeout" MUST be of 4 minutes or 207 longer. The value of the NAT idle-timeouts MAY be configurable. 209 NAT behavior for handling DCCP-Reset packets, or connections in 210 TIMEWAIT state is left unspecified. 212 6. Application Level Gateways 214 Contrary to TCP, DCCP is a loss-tolerant protocol. Therefore, 215 modifying the payload of DCCP packets may present a significant 216 additional challenge in maintaining sane any application-layer state 217 needed for an ALG to function. Additionaly, there are no known DCCP- 218 capable Application Level Gateways (ALGs) at the time of writing this 219 document. 221 REQ-6: If a NAT includes ALGs, it MUST NOT affect DCCP. 223 NOTE: This is not consistent with REQ-6 of [I-D.ietf-behave-tcp]. 225 7. Other Requirements Applicable to DCCP 227 A list of general and UDP specific NAT behavioral requirements are 228 described in [RFC4787]. A list of ICMP specific NAT behavioral 229 requirements are described in [I-D.ietf-behave-nat-icmp]. The 230 requirements listed below reiterate the requirements from these two 231 documents that directly affect DCCP. The following requirements do 232 not relax any requirements in [RFC4787] or 233 [I-D.ietf-behave-nat-icmp]. 235 7.1. Port Assignment 237 REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port 238 overloading" for DCCP. 240 7.2. Hairpinning Behavior 242 REQ-8: A NAT MUST support "Hairpinning" for DCCP. Futhermore, A 243 NAT's Hairpinning behavior MUST be of type "External source IP 244 address and port". 246 7.3. ICMP Responses to DCCP Packets 248 REQ-9: If a NAT translates DCCP, it SHOULD translate ICMP Destination 249 Unreachable (Type 3) messages. 251 REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the 252 NAT mapping or DCCP connection for which the ICMP was generated. 254 8. Requirements specific to DCCP 256 8.1. Partial checksum coverage 258 DCCP supports partial checksum coverage. A NAT will usually need to 259 perform incremental changes to the packet checksum field, as for 260 other IETF-defined protocols. However, if it needs to recalculate a 261 correct checksum value, it must take the checksum coverage into 262 account, as described in section 9.2 of [RFC4340]. 264 REQ-11: If a NAT translates a DCCP packet with a valid DCCP checksum, 265 it MUST ensure that the DCCP checksum is translated such that it is 266 valid after the translation. 268 REQ-12: A NAT MUST NOT modify the value of the DCCP Checksum 269 Coverage. 271 The Checksum Coverage field in the DCCP header determines the parts 272 of the packet that are covered by the Checksum field. This always 273 includes the DCCP header and options, but some or all of the 274 application data may be excluded as determined on a packet-by-packet 275 basis by the application. Changing the Checksum Coverage in the 276 network violates the integrity assumptions at the receiver and may 277 result in unpredictable or incorrect application behaviour. 279 8.2. Services codes 281 DCCP specifies a Service Code as a 4-byte value (32 bits) that 282 describes the application-level service to which a client application 283 wishes to connect [RFC4340]. 285 REQ-13: If a NAT translates a DCCP packet, it MUST NOT modify its 286 DCCP service code value. 288 Further guidance on the use of Service Codes by middleboxes, 289 including NATs, can be found in [I-D.ietf-dccp-serv-codes]. 291 9. DCCP without NAT support 293 If the NAT device cannot be updated to support DCCP, DCCP datagrams 294 can be encapsulated within an UDP transport header. Indeed, most NAT 295 devices are already capable of handling UDP. This is however beyond 296 the scope of this document. 298 10. Security Considerations 300 [RFC4787] discusses security considerations for NATs that handle IP 301 and unicast (UDP) traffic, all of which apply equally to this 302 document. Security concerns specific to handling DCCP packets are 303 discussed in this section. 305 REQ-1, and REQ-6 through REQ-13 do not introduce any new known 306 security concerns. 308 REQ-2 does not introduce any new known security concerns. While a 309 NAT may elect to keep track of some DCCP-specific per-flow state 310 (compared to UDP), it has no obligations to do so. 312 REQ-3 allows a NAT to adopt either a more secure, or a more 313 application-transparent filtering policy. This is already addressed 314 in [RFC4787] and [I-D.ietf-behave-tcp]. 316 Similar to [I-D.ietf-behave-tcp], REQ-4 of this document recommends a 317 NAT to respond to unsolicited inbound Listen and Sync packets with an 318 ICMP error delayed by a few seconds. Doing so may reveal the 319 presence of a NAT to an external attacker. Silently dropping the 320 Listen makes it harder to diagnose network problems. and forces 321 applications to wait for the DCCP stack to finish several 322 retransmissions before reporting an error. An implementer must 323 therefore understand and carefully weigh the effects of not sending 324 an ICMP error or rate-limiting such ICMP errors to a very small 325 number. 327 REQ-5 recommends that a NAT that passively monitors DCCP state keep 328 idle sessions alive for at least 124 minutes or 4 minutes depending 329 on the state of the connection. it may attempt to actively determine 330 the liveliness of a DCCP connection or let the NAT administrator 331 configure more conservative timeouts. 333 11. IANA Considerations 335 This document raises no IANA considerations. 337 12. Acknowledgments 339 The author would like to thank Gorry Fairhurst, Eddie Kohler, Dan 340 Wing, Alfred Hoenes, Magnus Westerlund, for his comments and help on 341 this document. 343 This memo borrows heavily from draft-ietf-behave-tcp-07, by S. Guha 344 (editor), K. Biswas, B. Ford, S. Sivakumar and P. Srisuresh. 346 13. References 347 13.1. Normative References 349 [I-D.ietf-behave-nat-icmp] Srisuresh, P., Ford, B., Sivakumar, S., 350 and S. Guha, "NAT Behavioral Requirements 351 for ICMP protocol", 352 draft-ietf-behave-nat-icmp-09 (work in 353 progress), September 2008. 355 [I-D.ietf-dccp-simul-open] Fairhurst, G., "DCCP Simultaneous-Open 356 Technique to Facilitate NAT/Middlebox 357 Traversal", draft-ietf-dccp-simul-open-04 358 (work in progress), October 2008. 360 [RFC2119] Bradner, S., "Key words for use in RFCs 361 to Indicate Requirement Levels", BCP 14, 362 RFC 2119, March 1997. 364 [RFC4340] Kohler, E., Handley, M., and S. Floyd, 365 "Datagram Congestion Control Protocol 366 (DCCP)", RFC 4340, March 2006. 368 [RFC4787] Audet, F. and C. Jennings, "Network 369 Address Translation (NAT) Behavioral 370 Requirements for Unicast UDP", BCP 127, 371 RFC 4787, January 2007. 373 13.2. Informative References 375 [I-D.ietf-behave-tcp] Guha, S., Biswas, K., Ford, B., 376 Sivakumar, S., and P. Srisuresh, "NAT 377 Behavioral Requirements for TCP", 378 draft-ietf-behave-tcp-08 (work in 379 progress), September 2008. 381 [I-D.ietf-dccp-serv-codes] Fairhurst, G., "The DCCP Service Code", 382 draft-ietf-dccp-serv-codes-08 (work in 383 progress), September 2008. 385 [RFC3424] Daigle, L. and IAB, "IAB Considerations 386 for UNilateral Self-Address Fixing 387 (UNSAF) Across Network Address 388 Translation", RFC 3424, November 2002. 390 Author's Address 392 Remi Denis-Courmont 393 VideoLAN project 395 EMail: rem@videolan.org 396 URI: http://www.videolan.org/ 398 Full Copyright Statement 400 Copyright (C) The IETF Trust (2008). 402 This document is subject to the rights, licenses and restrictions 403 contained in BCP 78, and except as set forth therein, the authors 404 retain all their rights. 406 This document and the information contained herein are provided on an 407 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 408 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 409 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 410 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 411 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 412 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 414 Intellectual Property 416 The IETF takes no position regarding the validity or scope of any 417 Intellectual Property Rights or other rights that might be claimed to 418 pertain to the implementation or use of the technology described in 419 this document or the extent to which any license under such rights 420 might or might not be available; nor does it represent that it has 421 made any independent effort to identify any such rights. Information 422 on the procedures with respect to rights in RFC documents can be 423 found in BCP 78 and BCP 79. 425 Copies of IPR disclosures made to the IETF Secretariat and any 426 assurances of licenses to be made available, or the result of an 427 attempt made to obtain a general license or permission for the use of 428 such proprietary rights by implementers or users of this 429 specification can be obtained from the IETF on-line IPR repository at 430 http://www.ietf.org/ipr. 432 The IETF invites any interested party to bring to its attention any 433 copyrights, patents or patent applications, or other proprietary 434 rights that may cover technology that may be required to implement 435 this standard. Please address the information to the IETF at 436 ietf-ipr@ietf.org.