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 Orchestrator supports the use of the DTLS protocol to secure UDP-based traffic (according to RFC 5764 and RFC 6347).  The Peeredge Orchestrator 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 Orchestrator’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 Orchestrator also includes the a=setup:actpass and a-fingerprint attributes in the SDP Offer.

When DTLS is enabled on the Peeredge Orchestrator’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 Orchestrator. This indicates that the Orchestrator 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 Orchestrator’s SDP answer, the Orchestrator 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.

For DTLS (SRTP) to SDES (RTP/SRTP) interoperability either the inbound or outbound Trunk Group must be configured to Anchor Media.

To enable support for DTLS, check Enable DTLS Support in the Anchor Media section of the Media Handling page in the Trunk Group configuration.