Datagram Transport Layer Security (DTLS)

Datagram Transport Layer Security (DTLS) is a communications protocol providing security to datagram-based applications. DTLS allows apps to communicate in a way designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the stream-oriented Transport Layer Security (TLS) protocol and is intended to provide similar security guarantees. The DTLS protocol datagram preserves the semantics of the underlying transport—the application does not suffer from the delays associated with stream protocols, but because it uses UDP or SCTP, the application has to deal with packet reordering, loss of datagram, and data larger than the size of a datagram network packet.

The Peeredge SBC supports the use of the DTLS protocol to secure UDP-based traffic (according to RFC 5764 and RFC 6347). DTLS allows datagram-based applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the stream-oriented TLS protocol, providing similar security. The Peeredge SBC can therefore interwork in mixed environments where one network may require DTLS and the other may require Session Description Protocol Security Descriptions (SDES) or even non-secure RTP. The Peeredge SBC supports DTLS negotiation for RTP-to-SRTP and SRTP-to-SRTP calls.

In contrast to SDES, DTLS key encryption is done over the media channel (UDP) and not over the signaling channel. Thus, DTLS-SRTP is generally known as "secured key exchange over media." DTLS is similar to TLS, but runs over UDP, whereas TLS is over TCP. Before the DTLS handshake, the peers exchange DTLS parameters (fingerprint and setup) and algorithm types in the SDP body of the SIP messages exchanged for establishing the call (INVITE request and response). The peers participate in a DTLS handshake during which they exchange certificates. These certificates are used to derive a symmetric key, which is used to encrypt data (SRTP) flow between the peers. A hash value calculated over the certificate is transported in the SDP using the 'a=fingerprint' attribute. At the end of the handshake, each side verifies that the certificate it received from the other side matches the fingerprint from the SDP.

To indicate DTLS support of the SDP offer/answer of the SIP message, the Peeredge SBC uses the UDP/TLS/RTP/SAVP token in the media line and the 'a=setup' attribute.

When DTLS is enabled on a Peeredge SBC’s Origination Customer or Termination Vendor Trunk Groups, the SBC includes the UDP/TLS/RTP/SAVP token in the media line in the SDP Offer. The SBC also includes the a=setup:actpass and a-fingerprint attributes in the SDP Offer.

When DTLS is enabled on the Peeredge SBC’s Origination Vendor or Termination Customer Trunk Groups, and the incoming SDP offer indicates support for DTLS, the SBC includes the UDP/TLS/RTP/SAVP token in the media line of the SDP Response as well as an a:fingerprint attributes. If the SDP Offer includes an a=setup:actpass attribute, then the SDP Response includes an a=setup:active attribute. If the SDP Offer includes an a=setup:active attribute, then the SDP Response includes an a=setup:passive attribute. If the SDP Offer includes an a=setup:passive attribute, then the SDP Response includes an a=setup:active attribute.

a=setup:actpass The device can either be the client or the server in the DTLS handshake.

a=setup:active The device is the client in the DTLS handshake.

a=setup:passive The device is the server in the DTLS handshake.

a=fingerprint Contains the hash value of the device's certificate used in the DTLS handshake.

The ‘a=setup:actpass' attribute value is used in the SDP offer by the Peeredge SBC. This indicates that the SBC is willing to be either a client ('active') or a server ('passive') in the handshake. If the ‘a=setup:active' attribute value is used in the SBC’s SDP answer, the SBC indicates that it wishes to be the client ('active') in the handshake.

m=audio 50258 UDP/TLS/RTP/SAVP 0 8 18 101

…

a=setup:actpass
a=fingerprint: SHA-1 \3A:AD:B9:B1:3C:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

DTLS cipher suite reuses the TLS cipher suite. The DTLS handshake is done for every new call configured for DTLS. In other words, unlike TLS, where the connection remains "open" for future calls, a new DTLS connection is required for every new call. Note that the entire authentication and key exchange for securing the media traffic is handled in the media path through DTLS. The signaling path is used only to verify the peers' certificate fingerprints. DTLS messages are multiplexed onto the same ports that are used for the media.