idnits 2.17.1 draft-ietf-behave-dccp-05.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 414. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 432. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 438. 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 (November 27, 2008) is 5629 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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-11 == Outdated reference: A later version (-08) exists of draft-ietf-dccp-simul-open-05 == 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 November 27, 2008 5 Intended status: BCP 6 Expires: May 31, 2009 8 Network Address Translation (NAT) Behavioral Requirements for the 9 Datagram Congestion Control Protocol 10 draft-ietf-behave-dccp-05.txt 12 Status of This Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 31, 2009. 37 Abstract 39 This document defines a set of requirements for NATs handling the 40 Datagram Congestion Control Protocol (DCCP). Those allow DCCP 41 applications, such as streaming applications to operate consistently. 42 These requirements are very similar to the TCP requirements for NATs 43 already published by the IETF. Ensuring that NATs meet this set of 44 requirements will greatly increase the likelihood that applications 45 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 [RFC5382], from which this 77 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 individual DCCP flows, as uniquely identified by the quadruple 95 (source 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 [RFC5382]. These justifications are not reproduced 117 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 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 for DCCP. 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. Where a NAT implements session timeouts, the default 205 value of the "established connection idle-timeout" MUST be of 124 206 minutes or longer and the default value of the "transitory connection 207 idle-timeout" MUST be of 4 minutes or longer. A NAT that implements 208 session timeouts may be configurable to use smaller values for the 209 NAT idle-timeouts. 211 NAT behavior for handling DCCP-Reset packets, or connections in 212 TIMEWAIT state is left unspecified. 214 6. Application Level Gateways 216 Contrary to TCP, DCCP is a loss-tolerant protocol. Therefore, 217 modifying the payload of DCCP packets may present a significant 218 additional challenge in maintaining sane any application-layer state 219 needed for an ALG to function. Additionally, there are no known 220 DCCP-capable Application Level Gateways (ALGs) at the time of writing 221 this document. 223 REQ-6: If a NAT includes ALGs, these ALGs MUST NOT affect DCCP. 225 NOTE: This is not consistent with REQ-6 of [RFC5382]. 227 7. Other Requirements Applicable to DCCP 229 A list of general and UDP specific NAT behavioral requirements are 230 described in [RFC4787]. A list of ICMP specific NAT behavioral 231 requirements are described in [I-D.ietf-behave-nat-icmp]. The 232 requirements listed below reiterate the requirements from these two 233 documents that directly affect DCCP. The following requirements do 234 not relax any requirements in [RFC4787] or 235 [I-D.ietf-behave-nat-icmp]. 237 7.1. Port Assignment 239 REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port 240 overloading" for DCCP. 242 7.2. Hairpinning Behavior 244 REQ-8: A NAT MUST support "Hairpinning" for DCCP. Furthermore, A 245 NAT's Hairpinning behavior MUST be of type "External source IP 246 address and port". 248 7.3. ICMP Responses to DCCP Packets 250 REQ-9: If a NAT translates DCCP, it SHOULD translate ICMP Destination 251 Unreachable (Type 3) messages. 253 REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the 254 NAT mapping or DCCP connection for which the ICMP was generated. 256 8. Requirements specific to DCCP 258 8.1. Partial checksum coverage 260 DCCP supports partial checksum coverage. A NAT will usually need to 261 perform incremental changes to the packet checksum field, as for 262 other IETF-defined protocols. However, if it needs to recalculate a 263 correct checksum value, it must take the checksum coverage into 264 account, as described in section 9.2 of [RFC4340]. 266 REQ-11: If a NAT translates a DCCP packet with a valid DCCP checksum, 267 it MUST ensure that the DCCP checksum is translated such that it is 268 valid after the translation. 270 REQ-12: A NAT MUST NOT modify the value of the DCCP Checksum 271 Coverage. 273 The Checksum Coverage field in the DCCP header determines the parts 274 of the packet that are covered by the Checksum field. This always 275 includes the DCCP header and options, but some or all of the 276 application data may be excluded as determined on a packet-by-packet 277 basis by the application. Changing the Checksum Coverage in the 278 network violates the integrity assumptions at the receiver and may 279 result in unpredictable or incorrect application behaviour. 281 8.2. Services codes 283 DCCP specifies a Service Code as a 4-byte value (32 bits) that 284 describes the application-level service to which a client application 285 wishes to connect [RFC4340]. 287 REQ-13: If a NAT translates a DCCP packet, it MUST NOT modify its 288 DCCP service code value. 290 Further guidance on the use of Service Codes by middleboxes, 291 including NATs, can be found in [I-D.ietf-dccp-serv-codes]. 293 9. DCCP without NAT support 295 If the NAT device cannot be updated to support DCCP, DCCP datagrams 296 can be encapsulated within an UDP transport header. Indeed, most NAT 297 devices are already capable of handling UDP. This is however beyond 298 the scope of this document. 300 10. Security Considerations 302 [RFC4787] discusses security considerations for NATs that handle IP 303 and unicast (UDP) traffic, all of which apply equally to this 304 document. Security concerns specific to handling DCCP packets are 305 discussed in this section. 307 REQ-1, and REQ-6 through REQ-13 do not introduce any new known 308 security concerns. 310 REQ-2 does not introduce any new known security concerns. While a 311 NAT may elect to keep track of some DCCP-specific per-flow state 312 (compared to UDP), it has no obligations to do so. 314 REQ-3 allows a NAT to adopt either a more secure, or a more 315 application-transparent filtering policy. This is already addressed 316 in [RFC4787] and [RFC5382]. 318 Similar to [RFC5382], REQ-4 of this document recommends a NAT to 319 respond to unsolicited inbound Listen and Sync packets with an ICMP 320 error delayed by a few seconds. Doing so may reveal the presence of 321 a NAT to an external attacker. Silently dropping the Listen makes it 322 harder to diagnose network problems and forces applications to wait 323 for the DCCP stack to finish several retransmissions before reporting 324 an error. An implementer must therefore understand and carefully 325 weigh the effects of not sending an ICMP error or rate-limiting such 326 ICMP errors to a very small number. 328 REQ-5 recommends that a NAT that passively monitors DCCP state keep 329 idle sessions alive for at least 124 minutes or 4 minutes depending 330 on the state of the connection. To protect against denial-of-service 331 attack filling its state storage capacity, a NAT may attempt to 332 actively determine the liveliness of a DCCP connection, or the NAT 333 administrator could configure more conservative timeouts. 335 11. IANA Considerations 337 This document raises no IANA considerations. 339 12. Acknowledgments 341 The author would like to thank Gorry Fairhurst, Eddie Kohler, Dan 342 Wing, Alfred Hoenes, Magnus Westerlund, Miguel Garcia, Catherine 343 Meadows, Tim Polk, Lars Eggert and Christian Vogt for their comments 344 and help on this document. 346 This memo borrows heavily from draft-ietf-behave-tcp-07, by S. Guha 347 (editor), K. Biswas, B. Ford, S. Sivakumar and P. Srisuresh. 349 13. References 350 13.1. Normative References 352 [I-D.ietf-behave-nat-icmp] Srisuresh, P., Ford, B., Sivakumar, S., 353 and S. Guha, "NAT Behavioral Requirements 354 for ICMP protocol", 355 draft-ietf-behave-nat-icmp-11 (work in 356 progress), November 2008. 358 [I-D.ietf-dccp-simul-open] Fairhurst, G., "DCCP Simultaneous-Open 359 Technique to Facilitate NAT/Middlebox 360 Traversal", draft-ietf-dccp-simul-open-05 361 (work in progress), October 2008. 363 [RFC2119] Bradner, S., "Key words for use in RFCs 364 to Indicate Requirement Levels", BCP 14, 365 RFC 2119, March 1997. 367 [RFC4340] Kohler, E., Handley, M., and S. Floyd, 368 "Datagram Congestion Control Protocol 369 (DCCP)", RFC 4340, March 2006. 371 [RFC4787] Audet, F. and C. Jennings, "Network 372 Address Translation (NAT) Behavioral 373 Requirements for Unicast UDP", BCP 127, 374 RFC 4787, January 2007. 376 13.2. Informative References 378 [I-D.ietf-dccp-serv-codes] Fairhurst, G., "The DCCP Service Code", 379 draft-ietf-dccp-serv-codes-08 (work in 380 progress), September 2008. 382 [RFC3424] Daigle, L. and IAB, "IAB Considerations 383 for UNilateral Self-Address Fixing 384 (UNSAF) Across Network Address 385 Translation", RFC 3424, November 2002. 387 [RFC5382] Guha, S., Biswas, K., Ford, B., 388 Sivakumar, S., and P. Srisuresh, "NAT 389 Behavioral Requirements for TCP", 390 BCP 142, RFC 5382, October 2008. 392 Author's Address 394 Remi Denis-Courmont 395 VideoLAN project 397 EMail: rem@videolan.org 398 URI: http://www.videolan.org/ 400 Full Copyright Statement 402 Copyright (C) The IETF Trust (2008). 404 This document is subject to the rights, licenses and restrictions 405 contained in BCP 78, and except as set forth therein, the authors 406 retain all their rights. 408 This document and the information contained herein are provided on an 409 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 410 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 411 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 412 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 413 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 414 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 416 Intellectual Property 418 The IETF takes no position regarding the validity or scope of any 419 Intellectual Property Rights or other rights that might be claimed to 420 pertain to the implementation or use of the technology described in 421 this document or the extent to which any license under such rights 422 might or might not be available; nor does it represent that it has 423 made any independent effort to identify any such rights. Information 424 on the procedures with respect to rights in RFC documents can be 425 found in BCP 78 and BCP 79. 427 Copies of IPR disclosures made to the IETF Secretariat and any 428 assurances of licenses to be made available, or the result of an 429 attempt made to obtain a general license or permission for the use of 430 such proprietary rights by implementers or users of this 431 specification can be obtained from the IETF on-line IPR repository at 432 http://www.ietf.org/ipr. 434 The IETF invites any interested party to bring to its attention any 435 copyrights, patents or patent applications, or other proprietary 436 rights that may cover technology that may be required to implement 437 this standard. Please address the information to the IETF at 438 ietf-ipr@ietf.org.