Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal
updates
- rfc-4340 — Datagram Congestion Control Protocol (DCCP)
Extracted elements (23)
A new packet type (DCCP-Listen, Type=10) was introduced rather than reusing DCCP-Request to avoid semantic overloading: DCCP-Request is the first packet of the three-way handshake, and dual use would require two distinct processing paths in hosts and stateful middleboxes, complicating implementation.
TCP-style simultaneous-open (both sides sending SYN/DCCP-Request) was explicitly rejected for DCCP because it would erase the clear client/server role distinction that DCCP relies on for feature negotiation (server-priority rule), closing state (CloseReq vs Close), Service Code multiplicity, and Init Cookie usage.
The 200ms retransmission interval with a maximum of 3 DCCP-Listen transmissions was chosen to ensure the cumulative 600ms window fits within the 1-second DCCP-Request retransmission timeout, while spacing packets sufficiently to avoid correlated loss on both wireless and wired paths.
The role-reversal technique (server temporarily acts as client to punch a hole, then reverts to passive) was rejected because it would require modifying DCCP's state machine, disrupting Service Code handling, Init Cookie support, and feature negotiation, which depend on stable, a priori knowledge of endpoint roles.
Using DCCP-Request as the listen signal was rejected because a client not yet in REQUEST state would respond with a DCCP-Reset (per RFC 4340 step 7), and a client already in REQUEST state would send a DCCP-Sync, neither of which is meaningful before sequence numbers are negotiated. A dedicated DCCP-Listen type allows clients to simply ignore the packet.
DCCP-Listen packets do not require special forwarding treatment and should traverse routers and middleboxes end-to-end. Middleboxes may use the address, port, and Service Code information to establish local forwarding state; NAT-specific processing is specified in RFC 5597.
No changes are required for backwards compatibility: a client conforming to this document interoperates with an RFC 4340 server without issue, and an RFC 4340 client silently ignores DCCP-Listen packets per existing step-1 processing. Servers performing passive-open without fully binding addresses/ports/Service Codes are unaffected.
A client in any state MUST silently discard any received DCCP-Listen packet unless it implements the optional triggered-retransmission procedure. An RFC 4340 client that receives a DCCP-Listen packet ignores it per step 1 of Section 8.1 of RFC 4340, which is also compliant with this document.
A DCCP server SHOULD set the Sequence Number field of a DCCP-Listen packet to 0. A DCCP client MUST ignore the Sequence Number field. Middleboxes MUST NOT interpret sequence numbers in DCCP-Listen packets.
A fully specified DCCP server endpoint SHOULD repeat sending DCCP-Listen packets while in the INVITED state at a 200-millisecond interval with at most 2 repetitions (3 total transmissions). After a further 200ms following the third packet, the server SHOULD transition to the LISTEN1 state.
Clients MUST ignore all options in received DCCP-Listen packets and endpoints MUST ignore any payload data in DCCP-Listen packets, since feature negotiation and data transfer are not possible before connection establishment.
Fully specified server endpoints SHOULD treat ICMP error messages received in response to a DCCP-Listen packet as 'soft errors' that do not cause a state transition, since network failures may be transient and a subsequent DCCP-Request may still succeed.
The Service Code field in a DCCP-Listen packet MUST correspond to a Service Code the server is actually offering for a connection identified by the same source IP address and source port. The specific Service Code must be communicated out-of-band from client to server prior to sending DCCP-Listen.
The X bit in a DCCP-Listen packet MUST be set to 1, requiring use of the long (generic) sequence number header, since short sequence numbers cannot be negotiated before a connection is established.
An optional client optimisation allows a client in the REQUEST state to immediately retransmit its DCCP-Request upon receiving the first DCCP-Listen packet, avoiding a timeout wait. The client MUST perform only one such triggered retransmission per connection and SHOULD increase the exponential-backoff timer interval afterward. DCCP-Listen packets received in all other client states MUST be silently discarded.
The DCCP-Listen packet is a new DCCP packet type (Type=10) that a fully specified server sends to a known client to punch a hole through middleboxes. It carries Source Port, Destination Port, Sequence Number, and Service Code fields in the standard generic header format, but sequence numbers have no meaning in this context.
IANA registered the new DCCP packet type 'DCCP-Listen' with decimal value 10 in the IANA DCCP Packet Types Registry, referencing this document (RFC 5596).
A DCCP-Listen packet sent to a specific client exposes unencrypted server state (IP address, port, Service Code) on the network path. An on-path attacker could observe this and spoof a DCCP-Request or DCCP-Reset to inject data or deny the connection. This is comparable to existing on-path attack exposure once any DCCP session is initiated.
A DCCP server SHOULD by default permit generation of DCCP-Listen packets. A server MAY disable DCCP-Listen generation to prevent information disclosure, but doing so may inhibit middlebox traversal without affecting other DCCP state transitions.
If the out-of-band signaling channel is not encrypted, an eavesdropper could forge a DCCP-Listen packet towards the client; however, the client only processes DCCP-Listen if the server IP:port matches an existing REQUEST-state connection, preventing redirection to a different server.
This specification requires the server to hold per-connection state (bound to client IP:port and Service Code) before the three-way handshake completes, removing the protection offered by RFC 4340's Init Cookie mechanism. The security impact is expected to be minimal and depends on the security properties of the out-of-band signaling channel (e.g., SIP/SDP).
Two new server states are introduced: INVITED (fully specified server socket generating DCCP-Listen packets toward the client; transitions to LISTEN1 on receipt of DCCP-Request) and LISTEN1 (passive listening without further DCCP-Listen generation; transitions to RESPOND on receipt of DCCP-Request). The existing path CLOSED→LISTEN→RESPOND is unchanged for unspecified servers.
The DCCP-Listen packet reuses the generic DCCP header: 16-bit Source Port, 16-bit Dest Port, 8-bit Data Offset, 4-bit CCVal, 4-bit CsCov, 16-bit Checksum, 3-bit Res, 4-bit Type (value 10), 1-bit X (must be 1), 8-bit Reserved, 48-bit Sequence Number (ignored), and 32-bit Service Code. Data Offset MUST be ≥5 (20 bytes); CCVal and CsCov MUST be zero.