idnits 2.17.1 draft-ietf-behave-dccp-02.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 407. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 431. 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 (September 11, 2008) is 5706 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-08 == Outdated reference: A later version (-08) exists of draft-ietf-dccp-simul-open-01 == Outdated reference: A later version (-11) exists of draft-ietf-dccp-serv-codes-06 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 September 11, 2008 5 Intended status: Standards Track 6 Expires: March 15, 2009 8 Network Address Translation (NAT) Behavioral Requirements for DCCP 9 draft-ietf-behave-dccp-02.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 March 15, 2009. 36 Abstract 38 This document defines a set of requirements for DCCP-capable NATs 39 that would allow certain applications, such as streaming applications 40 to operate consistently. These requirements are very similar to the 41 TCP requirements for NATs already published by this IETF working 42 group. Developing NATs that meet this set of requirements will 43 greatly increase the likelihood that applications using DCCP will 44 function properly. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 3 51 4. DCCP Connection Initiation . . . . . . . . . . . . . . . . . . 4 52 5. NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . . 5 53 6. Application Level Gateways . . . . . . . . . . . . . . . . . . 6 54 7. Other Requirements Applicable to DCCP . . . . . . . . . . . . . 6 55 8. Requirements specific to DCCP . . . . . . . . . . . . . . . . . 7 56 9. DCCP without NAT support . . . . . . . . . . . . . . . . . . . 7 57 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 58 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 59 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 60 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 13.1. Normative References . . . . . . . . . . . . . . . . . . . 8 62 13.2. Informative References . . . . . . . . . . . . . . . . . . 9 64 1. Introduction 66 For historical reasons, NAT devices are not typically capable of 67 handling datagrams and flows for applications using the Datagram 68 Congestion Control Protocol (DCCP)[RFC4340]. 70 This draft discusses the technical issues involved, and proposes a 71 set of requirements for NAT devices to handle DCCP in a way that 72 enables communications when either or both of the DCCP endpoints are 73 located behind one or more NAT devices. All definitions and 74 requirements in [RFC4787] are inherited here. The requirements are 75 otherwise designed similarly to those in [I-D.ietf-behave-tcp], from 76 which this memo borrows its structure and much of its content. 78 Note however that, if both endpoints are hindered by NAT devices, the 79 normal model of asymmetric connection model of DCCP will not work. A 80 simultaneous open must be performed, as in 81 [I-D.ietf-dccp-simul-open]. Also, a separate unspecified mechanism 82 may be needed, such as UNSAF protocols, if an endpoint needs to learn 83 its own external NAT mappings. 85 2. Definitions 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 This documentation uses the term "DCCP connection" to refer to 92 invidual DCCP flows, as uniquely identified by the quadruple (source 93 and destination IP addresses and DCCP ports) at a given time. 95 This document uses the term "NAT mapping" to refer to state at the 96 NAT necessary for network address and port translation of DCCP 97 connections. This document also uses the terms "endpoint-independent 98 mapping", "address-dependent mapping", "address and port-dependent 99 mapping", "filtering behavior", "endpoint-independent filtering", 100 "address-dependent filtering", "address and port-dependent 101 filtering", "port assignment", "port overloading", "hairpinning", and 102 "external source IP address and port" as defined in [RFC4787]. 104 3. Applicability statement 106 This document applies to NAT devices that want to handle DCCP 107 datagrams. It is not the intent of this document to deprecate the 108 overwhelming majority of deployed NAT devices. These NATs are simply 109 not expected to handle DCCP, so this memo is not applicable to them. 111 Expected NAT behaviors applicable to DCCP connections are very 112 similar to those applicable to TCP connections (with the exception or 113 REQ-6 below). The following requirements are discussed and justified 114 extensively in [I-D.ietf-behave-tcp]. These justifications are not 115 reproduced here for the sake of brevity. 117 In addition to the usual changes to the IP header (in particular the 118 IP addresses), NAT devices need to mangle: 120 o the DCCP source port, for outgoing packets, depending on the NAT 121 mapping 123 o the DCCP destination port, for incoming packets, depending on the 124 NAT mapping 126 o the DCCP checksum, to compensate for IP address and port number 127 modifications. 129 Because changing the the source or destination IP address of a DCCP 130 packet will normally invalidate the DCCP checksum, it is not possible 131 to use DCCP through a NAT without dedicated support. Some NAT 132 devices are known to provide a "generic" transport protocol support, 133 whereby only the IP header is mangled. That scheme is not sufficient 134 to support DCCP in any case. 136 4. DCCP Connection Initiation 138 4.1. Address and Port Mapping Behavior 140 A NAT uses a mapping to translate packets for each DCCP connection. 141 A mapping is dynamically allocated for connections initiated from the 142 internal side, and potentially reused for certain subsequent 143 connections. NAT behavior regarding when a mapping can be reused 144 differs for different NATs as described in [RFC4787]. 146 REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior for 147 DCCP. 149 4.2. Internally Initiated Connections 151 REQ-2: A NAT MUST support all valid sequences of DCCP packets 152 (defined in [RFC4340] and its updates) for connections initiated both 153 internally as well as externally when the connection is permitted by 154 the NAT. 156 In particular, in addition to handling the DCCP 3-way handshake mode 157 of connection initiation, A NAT MUST handle the DCCP simultaneous- 158 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 packet before it may respond with 182 an ICMP Port Unreachable or an ICMP Protocol Unreachable error. If 183 during this interval the NAT receives and translates an outbound 184 DCCP-Request packet for the connection the NAT MUST silently drop the 185 original unsolicited inbound DCCP-Listen packet. Otherwise the NAT 186 SHOULD send an ICMP Port Unreachable error (Type 3, Code 3) for the 187 original DCCP-Listen, unless the security policy forbids it. 189 5. NAT Session Refresh 191 The "established connection idle-timeout" for a NAT is defined as the 192 minimum time a DCCP connection in the established phase must remain 193 idle before the NAT considers the associated session a candidate for 194 removal. The "transitory connection idle-timeout" for a NAT is 195 defined as the minimum time a DCCP connection in the CLOSEREQ or 196 CLOSING phases must remain idle before the NAT considers the 197 associated session a candidate for removal. DCCP connections in the 198 TIMEWAIT state are not affected by the "transitory connection idle- 199 timeout". 201 REQ-5: If a NAT cannot determine whether the endpoints of a DCCP 202 connection are active, it MAY abandon the session if it has been idle 203 for some time. In such cases, the value of the "established 204 connection idle-timeout" MUST be of 2 hours 4 minutes or longer. The 205 value of the "transitory connection idle-timeout" MUST be of 4 206 minutes or longer. The value of the NAT idle-timeouts MAY be 207 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 additionnal challenge in maintaining sane any application-layer state 217 needed for an ALG to function. Additionnaly, there are no known 218 DCCP-capable Application Level Gateways (ALGs) at the time of writing 219 this 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. Security concerns specific to handling 302 DCCP packets are discussed in this section. 304 REQ-1, and REQ-6 through REQ-13 do not introduce any new known 305 security concerns. 307 REQ-2 does not introduce any new known security concerns. While a 308 NAT may elect to keep track of some DCCP-specific per-flow state 309 (compared to UDP), it has no obligations to do so. 311 REQ-3 allows a NAT to adopt either a more secure, or a more 312 application-transparent filtering policy. This is already addressed 313 in [RFC4787] and [I-D.ietf-behave-tcp]. 315 Similar to [I-D.ietf-behave-tcp], REQ-4 of this document recommends a 316 NAT to respond to unsolicited inbound Sync packets with an ICMP error 317 delayed by a few seconds. Doing so may reveal the presence of a NAT 318 to an external attacker. Silently dropping the Sync makes it harder 319 to diagnose network problems and forces applications to wait for the 320 DCCP stack to finish several retransmissions before reporting an 321 error. An implementer must therefore understand and carefully weigh 322 the effects of not sending an ICMP error or rate-limiting such ICMP 323 errors to a very small number. 325 REQ-5 recommends that a NAT that passively monitors DCCP state keep 326 idle sessions alive for at least 2 hours 4 minutes or 4 minutes 327 depending on the state of the connection. If a NAT is undergoing a 328 denial of attack, it may attempt to actively determine the liveliness 329 of a DCCP connection or let the NAT administrator configure more 330 conservative timeouts. 332 11. IANA Considerations 334 This document raises no IANA considerations. 336 12. Acknowledgments 338 The author would like to thank Gorry Fairhurst for his comments and 339 help on this document. 341 This memo borrows heavily from draft-ietf-behave-tcp-07, by S. Guha 342 (editor), K. Biswas, B. Ford, S. Sivakumar and P. Srisuresh. 344 13. References 346 13.1. Normative References 348 [I-D.ietf-behave-nat-icmp] Srisuresh, P., Ford, B., Sivakumar, S., 349 and S. Guha, "NAT Behavioral Requirements 350 for ICMP protocol", 351 draft-ietf-behave-nat-icmp-08 (work in 352 progress), June 2008. 354 [I-D.ietf-dccp-simul-open] Fairhurst, G. and G. Renker, "DCCP 355 Simultaneous-Open Technique to Facilitate 356 NAT/Middlebox Traversal", 357 draft-ietf-dccp-simul-open-01 (work in 358 progress), June 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-06 (work in 383 progress), June 2008. 385 Author's Address 387 Remi Denis-Courmont 388 VideoLAN project 390 EMail: rem@videolan.org 391 URI: http://www.videolan.org/ 393 Full Copyright Statement 395 Copyright (C) The IETF Trust (2008). 397 This document is subject to the rights, licenses and restrictions 398 contained in BCP 78, and except as set forth therein, the authors 399 retain all their rights. 401 This document and the information contained herein are provided on an 402 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 403 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 404 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 405 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 406 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 407 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 409 Intellectual Property 411 The IETF takes no position regarding the validity or scope of any 412 Intellectual Property Rights or other rights that might be claimed to 413 pertain to the implementation or use of the technology described in 414 this document or the extent to which any license under such rights 415 might or might not be available; nor does it represent that it has 416 made any independent effort to identify any such rights. Information 417 on the procedures with respect to rights in RFC documents can be 418 found in BCP 78 and BCP 79. 420 Copies of IPR disclosures made to the IETF Secretariat and any 421 assurances of licenses to be made available, or the result of an 422 attempt made to obtain a general license or permission for the use of 423 such proprietary rights by implementers or users of this 424 specification can be obtained from the IETF on-line IPR repository at 425 http://www.ietf.org/ipr. 427 The IETF invites any interested party to bring to its attention any 428 copyrights, patents or patent applications, or other proprietary 429 rights that may cover technology that may be required to implement 430 this standard. Please address the information to the IETF at 431 ietf-ipr@ietf.org.