RFC 5597

RFC 5597: Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol 🎀

okay so bestie, this is RFC 5597, and the title says it all: NAT behavioral requirements for DCCP. It was written by R. Denis-Courmont from the VideoLAN project and dated September 2009 🦋. It's a Best Current Practice (the header calls it BCP 150, Category: Best Current Practice), so it's the IETF's recommended way of doing things rather than a standards-track spec. The header doesn't list any documents it obsoletes or updates. 💅

Abstract ✨

okay so this doc lays out a set of requirements for NATs that handle the Datagram Congestion Control Protocol (DCCP) 🌸. The whole point is letting DCCP apps, like streaming stuff, act consistently. These requirements are super similar to the TCP ones for NATs that the IETF already published, so it's giving déjà vu in the best way. If NATs actually meet this set, apps using DCCP are way more likely to work properly. iykyk 🫶

Status of This Memo ✨

this one is an Internet Best Current Practice for the Internet Community 🧚. It's also asking people to talk about it and send suggestions for improvements, so join the convo! Distribution of this memo is unlimited 🌈.

Copyright and License Notice ✨

the copyright is (c) 2009 IETF Trust and the persons identified as the document authors, with all rights reserved 💜.

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date it was published. Read those carefully, bestie, because they explain your rights and restrictions for this doc 📜. Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the BSD License describes.

this document might have material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from whoever controls that copyright, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🙈.

Table of Contents ✨

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.  Applicability Statement . . . . . . . . . . . . . . . . . . . . 3
4.  DCCP Connection Initiation  . . . . . . . . . . . . . . . . . . 4
5.  NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . . 5
6.  Application-Level Gateways  . . . . . . . . . . . . . . . . . . 5
7.  Other Requirements Applicable to DCCP . . . . . . . . . . . . . 5
8.  Requirements Specific to DCCP . . . . . . . . . . . . . . . . . 6
9.  DCCP without NAT Support  . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
12. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8

---

1. Introduction 🌸

for historical reasons, NAT devices usually can't handle the datagrams and flows for apps that use DCCP [RFC4340] 😭. That's the core problem this doc is here to fix.

this memo digs into the technical issues and proposes a set of requirements so NAT devices can handle DCCP. The goal is communication working even when one or both DCCP endpoints are sitting behind one or more NAT devices 💖. All the definitions and requirements in [RFC4787] are inherited here. Otherwise, the requirements are designed similarly to the ones in [RFC5382], and this memo borrows its structure and a lot of its content from that one 🦋.

BUT, note that if both endpoints are hindered by NAT devices, the normal DCCP model of an asymmetric connection won't work. A simultaneous-open has to be performed, as described in [RFC5596] ⚠️. Also, a separate mechanism that isn't specified here might be needed, like Unilateral Self Address Fixing (UNSAF) [RFC3424] protocols, if an endpoint needs to learn its own external NAT mappings 🔍.

2. Definitions 💅

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📚.

this doc uses the term "DCCP connection" to mean individual DCCP flows, uniquely identified by the quadruple (source and destination IP addresses and DCCP ports) at a given time 🎀.

this doc also uses the term "NAT mapping" for a state at the NAT that's needed for network address and port translation of DCCP connections. It additionally uses the terms "endpoint-independent mapping", "address-dependent mapping", "address and port-dependent mapping", "filtering behavior", "endpoint-independent filtering", "address-dependent filtering", "address and port-dependent filtering", "port assignment", "port overloading", "hairpinning", and "external source IP address and port", all as defined in [RFC4787] ✨.

3. Applicability Statement 🧚

this document applies to NAT devices that want to handle DCCP datagrams. It's not trying to deprecate the overwhelming majority of deployed NAT devices 🙌. Those NATs just aren't expected to handle DCCP, so this memo doesn't apply to them.

expected NAT behaviors for DCCP connections are very similar to the ones for TCP connections, except for REQ-6 below 🌈. The requirements listed here are discussed and justified at length in [RFC5382]. Those justifications aren't copied here, for the sake of brevity.

besides the usual changes to the IP header (especially the IP addresses), NAT devices need to mangle:

• the DCCP source port for outgoing packets, depending on the NAT mapping,
• the DCCP destination port for incoming packets, depending on the NAT mapping, and
• the DCCP checksum, to compensate for IP address and port number modifications.

because changing the source or destination IP address of a DCCP packet will normally invalidate the DCCP checksum, you can't use DCCP through a NAT without dedicated support 💀. Some NAT devices are known to offer "generic" transport-protocol support, where only the IP header gets mangled. That scheme is not enough to support DCCP, sadly 😭.

4. DCCP Connection Initiation 🦋

4.1. Address and Port Mapping Behavior

a NAT uses a mapping to translate packets for each DCCP connection 🗺️. A mapping is dynamically allocated for connections initiated from the internal side, and it can potentially be reused for certain later connections. How a NAT decides when a mapping can be reused differs between NATs, as described in [RFC4787].

REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior for DCCP. 💖

4.2. Established Connections

REQ-2: A NAT MUST support all valid sequences of DCCP packets (defined in [RFC4340] and its updates) for connections initiated both internally and externally, when the NAT permits the connection ✨. In particular, in addition to handling the DCCP 3-way handshake mode of connection initiation, a NAT MUST handle the DCCP simultaneous-open mode of connection initiation, defined in [RFC5596] 🤝. That mode updates DCCP by adding a new packet type: DCCP-Listen. The DCCP-Listen packet communicates the info needed to uniquely identify a DCCP session. NATs may use the connection information (address, port, Service Code) to set up local forwarding state 🔥.

4.3. Externally Initiated Connections

REQ-3: If application transparency matters most, it is RECOMMENDED that a NAT have an "Endpoint-independent filtering" behavior for DCCP. If a stricter filtering behavior matters most, it is RECOMMENDED that a NAT have an "Address-dependent filtering" behavior for DCCP 🛡️.

• The filtering behavior MAY be an option that the administrator of the NAT can configure.
• The filtering behavior for DCCP MAY be independent of the filtering behavior for any other transport-layer protocol, such as UDP, UDP-Lite, TCP, and SCTP (Stream Control Transmission Protocol).

REQ-4: A NAT MUST wait for at least 6 seconds from the reception of an unsolicited, inbound DCCP-Listen or DCCP-Sync packet before it may respond with an ICMP Port Unreachable error, an ICMP Protocol Unreachable error, or a DCCP-Reset ⏳. If, during this interval, the NAT receives and translates an outbound DCCP-Request packet for the connection, the NAT MUST silently drop the original unsolicited, inbound DCCP-Listen packet 🫥. Otherwise, the NAT SHOULD send an ICMP Port Unreachable error (Type 3, Code 3) for the original DCCP-Listen, unless the security policy forbids it 🚫.

5. NAT Session Refresh 🌙

the "established connection idle-timeout" for a NAT is defined as the minimum time a DCCP connection in the established phase must stay idle before the NAT considers the associated session a candidate for removal. The "transitory connection idle-timeout" for a NAT is defined as the minimum time a DCCP connection in the CLOSEREQ or CLOSING phases must stay idle before the NAT considers the associated session a candidate for removal. DCCP connections in the TIMEWAIT state aren't affected by the "transitory connection idle-timeout" 🕰️.

REQ-5: If a NAT can't determine whether the endpoints of a DCCP connection are active, it MAY abandon the session if it has been idle for some time 😴. Where a NAT implements session timeouts, the default value of the "established connection idle-timeout" MUST be 124 minutes or longer, and the default value of the "transitory connection idle-timeout" MUST be 4 minutes or longer. A NAT that implements session timeouts may be configurable to use smaller values for the NAT idle-timeouts ⚙️.

NAT behavior for handling DCCP-Reset packets, or connections in the TIMEWAIT state, is left unspecified 🤷‍♀️.

6. Application-Level Gateways 🎀

unlike TCP, DCCP is a loss-tolerant protocol 🌷. So modifying the payload of DCCP packets may be a big extra challenge when it comes to keeping any application-layer state that an Application Level Gateway (ALG) needs to work properly. There are also no known DCCP-capable ALGs at the time of writing this document 😬.

REQ-6: If a NAT includes ALGs, these ALGs MUST NOT affect DCCP. 🙅‍♀️

NOTE: This is not consistent with REQ-6 of [RFC5382]. 👀

7. Other Requirements Applicable to DCCP 📋

a list of general and UDP-specific NAT behavioral requirements is in [RFC4787], and a list of ICMP-specific NAT behavioral requirements is in [RFC5508]. The requirements below repeat the ones from those two documents that directly affect DCCP 💕. None of the following requirements relax any requirements in [RFC4787] or [RFC5508].

7.1. Port Assignment

REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading" for DCCP. 🚫

7.2. Hairpinning Behavior

REQ-8: A NAT MUST support "hairpinning" for DCCP. Furthermore, a NAT's hairpinning behavior MUST be of type "External source IP address and port". 🔁✨

7.3. ICMP Responses to DCCP Packets ✨

okay so ICMP is basically the internet's "hey, something went wrong" note 💌, and these two requirements are about what a NAT does with those notes for DCCP. 🫶

REQ-9: If a NAT translates DCCP, it SHOULD translate ICMP Destination Unreachable (Type 3) messages. 🎀

REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the NAT mapping or DCCP connection for which the ICMP was generated. 🛡️ the mapping and the connection should not get nuked just because an ICMP showed up, periodt 💅

8. Requirements Specific to DCCP 👑

8.1. Partial Checksum Coverage 🧩

DCCP supports partial checksum coverage 🎯. A NAT will usually need to make incremental changes to the packet Checksum field, same as for other IETF-defined protocols. BUT if it needs to recalculate a correct checksum value, it must take the checksum coverage into account, as described in Section 9.2 of [RFC4340]. lowkey the most important detail in this whole section 🔥

REQ-11: If a NAT translates a DCCP packet with a valid DCCP checksum, it MUST ensure that the DCCP checksum is translated such that it is valid after the translation. ✅

REQ-12: A NAT MUST NOT modify the value of the DCCP Checksum Coverage. 🙅‍♀️

The Checksum Coverage field in the DCCP header decides which parts of the packet the Checksum field covers 🦋. That always includes the DCCP header and options, but some or all of the application data may be excluded, and the application decides that on a packet-by-packet basis. So if the network changes the Checksum Coverage, the integrity assumptions at the receiver get violated, and the result may be unpredictable or incorrect application behaviour. 😭 not it being a mess on the wire

8.2. Services Codes 🍓

DCCP specifies a Service Code as a 4-byte value (32 bits) that describes the application-level service a client application wants to connect to [RFC4340]. ✨

REQ-13: If a NAT translates a DCCP packet, it MUST NOT modify its DCCP Service Code value. 🙈

If you want more on how middleboxes, NATs included, should handle Service Codes, go check [RFC5595] 📚

9. DCCP without NAT Support 🧚

If the NAT device cannot be updated to support DCCP, DCCP datagrams can be encapsulated within a UDP transport header 🦋. Honestly, most NAT devices already handle UDP, so this is a real fallback option. This is however beyond the scope of this document. 💜

10. Security Considerations 🔐

[RFC4787] discusses security considerations for NATs that handle IP and unicast (UDP) traffic, and all of that applies equally to this document 🌈. The security concerns specific to handling DCCP packets are discussed in this section.

REQ-1 and REQ-6 through REQ-13 do not introduce any new known security concerns. ✅

REQ-2 does not introduce any new known security concerns. While a NAT may elect to keep track of some DCCP-specific, per-flow state (compared to UDP), it has no obligations to do so. 🧠

REQ-3 allows a NAT to adopt either a more secure or a more application-transparent filtering policy. This is already addressed in [RFC4787] and [RFC5382]. 🛡️

Similar to [RFC5382], REQ-4 of this document recommends that a NAT respond to unsolicited, inbound Listen and Sync packets with an ICMP error delayed by a few seconds. ⚠️ Doing so may reveal the presence of a NAT to an external attacker. Silently dropping the Listen makes it harder to diagnose network problems, and it forces applications to wait for the DCCP stack to finish several retransmissions before reporting an error. An implementer must therefore understand and carefully weigh the effects of not sending an ICMP error or rate-limiting such ICMP errors to a very small number. 🫠 this is a real trade-off, bestie, don't skip it

Warning: the trade-off here is real. Revealing the NAT to an attacker and making problems harder to debug are both on the table, so think it through before you decide. 💀

REQ-5 recommends that a NAT that passively monitors DCCP state keep idle sessions alive for at least 124 minutes or 4 minutes, depending on the state of the connection. ⏳ To protect against denial-of-service attacks filling its state storage capacity, a NAT may attempt to actively determine the liveliness of a DCCP connection, or the NAT administrator could configure more conservative timeouts. 🚨 denial-of-service attacks are NOT it, so guard that state table 🛡️

11. Acknowledgments 🫶

The author would like to thank Gorry Fairhurst, Eddie Kohler, Dan Wing, Alfred Hoenes, Magnus Westerlund, Miguel Garcia, Catherine Meadows, Tim Polk, Lars Eggert, and Christian Vogt for their comments and help on this document. 💖

This memo borrows heavily from [RFC5382] by S. Guha (editor), K. Biswas, B. Ford, S. Sivakumar, and P. Srisuresh. 🌸

12. References 📚

12.1. Normative References

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
• [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
• [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
• [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/ Middlebox Traversal", RFC 5596, September 2009.

12.2. Informative References

• [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
• [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
• [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.

Author's Address 🎀

Remi Denis-Courmont VideoLAN project

EMail: rem@videolan.org URI: http://www.videolan.org/