UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)
updated by
- rfc-8842 — Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)
Extracted elements (28)
DTLS was chosen as the security layer because its design is well understood, implementations are widely available, no DTLS extensions are required, and UDPTL can be transported simply by inserting the DTLS layer between UDPTL and UDP with no modifications to higher layers.
Security was focused on UDPTL-based fax transport rather than T.38-over-RTP because UDPTL is by far the dominant fax-over-IP transport; T.38 over RTP (which would use SRTP) accounts for a negligible share of implementations and never gained market traction.
The security model leverages SIP signaling integrity (e.g., SIP Identity) rather than requiring confidentiality of signaling, because verifying the integrity of exchanged SDP is sufficient to prevent hijacking of the DTLS handshake via man-in-the-middle attack.
If a remote endpoint does not support UDPTL over DTLS and secure fax is required, a fax media stream cannot be established. If secure fax is only preferred, SDP Capability Negotiation (RFC 5939) can be used to offer both UDP/TLS/UDPTL and plain UDPTL/UDP in the same offer.
The DTLS record layer 'application_data' packet carries no indicator of whether it holds UDPTL or another protocol; therefore, a dedicated DTLS association per UDPTL stream must be negotiated explicitly via SDP before media can flow.
An endpoint MUST create an SDP media description ('m=' line) for each UDPTL-over-DTLS media stream and MUST assign a UDP/TLS/UDPTL value to the 'proto' field of that 'm=' line.
During rekeying, receivers MUST maintain both the old and new sets of keys for some time after the DTLS handshake completes, in order to decrypt and verify older packets that may arrive out of order.
If a cipher suite with a certificate is selected during the DTLS handshake, the received certificate MUST match the fingerprint in the SDP 'fingerprint' attribute; if it does not match, the endpoint MUST immediately tear down the media session.
If using a cipher suite with an associated certificate, the endpoint MUST include an SDP 'fingerprint' attribute and MUST support SHA-256 for generating and verifying the fingerprint value, with SHA-256 use preferred.
Once the DTLS handshake is successfully completed, UDPTL packets MUST be transported in DTLS record layer 'application_data' packets to prevent insecure facsimile data transmission.
The answerer MUST assign the SDP 'setup' attribute a value of 'active' or 'passive' and MUST NOT assign 'holdconn'. If 'active' is assigned, the answerer MUST initiate a DTLS handshake by sending a DTLS ClientHello toward the offerer.
The endpoint MUST NOT use the SDP 'connection' attribute and MUST use the SDP 'setup' attribute to negotiate TLS roles for the UDPTL-over-DTLS transport connection.
The offerer SHOULD assign the SDP 'setup' attribute a value of 'actpass' by default; it MUST NOT assign 'holdconn'. If 'actpass' or 'passive' is assigned, the offerer MUST be prepared to receive a DTLS ClientHello before receiving the SDP answer.
The UA MUST send STUN packets directly over UDP, not over DTLS. The UA MUST support demultiplexing incoming packets: first byte 0 or 1 indicates STUN; first byte between 20 and 63 inclusive indicates DTLS.
UDPTL over DTLS MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, MUST prefer the ECDHE variant and any other PFS cipher suites, and implementations SHOULD disable TLS-level compression.
When ICE is used, UAs MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association, ensuring only one DTLS handshake occurs even if multiple valid candidate pairs exist.
When making anonymous calls, a new self-signed certificate SHOULD be used for each call, and certificate attributes such as 'subjectAltName' and 'commonName' MUST NOT contain information that allows user correlation or identification.
For anonymous calls, a fresh self-signed certificate SHOULD be generated per call, and attributes such as 'subjectAltName' and 'commonName' MUST NOT carry identifying or correlatable information, preventing certificate-based user tracking.
Session modification is supported: endpoints MAY reuse an existing DTLS association if fingerprint values and transport parameters are unchanged; otherwise they negotiate a new association and delete the previous one, maintaining both during the transition.
The SDP 'proto' field value 'UDP/TLS/UDPTL' is defined to indicate a UDPTL-over-DTLS media stream in an SDP 'm=' line. This value is used together with the SDP 'setup' and 'fingerprint' attributes from RFC 4145 and RFC 4572.
The SDP 'setup' attribute (RFC 4145) is used to negotiate DTLS roles: 'active' (sends ClientHello), 'passive' (receives ClientHello), or 'actpass' (willing to do either). The value 'holdconn' MUST NOT be used.
This document adds the value 'UDP/TLS/UDPTL' to the SDP 'proto' field registry within the 'Session Description Protocol (SDP) Parameters' IANA registry, as specified in Section 8.2.2 of RFC 4566.
DTLS certificate authentication is tied to the SDP fingerprint: each side verifies that the certificate received in the DTLS handshake matches the fingerprint advertised in SDP, binding the media-plane security to the integrity of the SIP/SDP signaling.
Issuing and deploying PKIX certificates to all clients is not realistic in most fax deployment scenarios; the design therefore relies on self-signed certificates bound via SDP fingerprints rather than CA-issued certificates for the client role.
Without a signaling integrity mechanism (e.g., SIP Identity per RFC 4474, or S/MIME), security is limited to defense against passive eavesdropping only. An active attacker controlling both signaling and the media plane can mount a man-in-the-middle attack (R-SIG-MEDIA threat).
DTLS association lifecycle: ICE connectivity checks complete → DTLS handshake begins → handshake completes, UDPTL transport begins → on session modification, old and new associations coexist → old association deleted once new one is established. On ICE restart, handshake is repeated and new association replaces old.
Packet demultiplexing on the shared UDP port uses the first byte value: 0–1 indicates STUN, 20–63 indicates DTLS. This allows STUN (for NAT traversal) and DTLS to share the same IP address and port.
UDPTL is carried directly in DTLS record layer 'application_data' packets. No framing or multiplexing indicator is added within the DTLS payload, requiring out-of-band (SDP) negotiation to establish a dedicated DTLS association for UDPTL.