ESBC Support for DTLS-SRTP

The ESBC aligns with the applicable standards to support DTLS-SRTP, including RFC 5763 and RFC 5764. Alignment with these standards defines much of the ESBC behavior with respect to supporting DTLS for SRTP.

The ESBC supports broad, standards-based requirements including:

Authenticating the endpoints using fingerprints
DTLS Extension to Establish Keys for the SRTP
Support of the "use_srtp” extension without an MKI value defined
Support for multiple media sessions from an endpoint, such as audio and video, with separate DTLS session establishment exchange per media session
Using information within SIP/SDP sessions to identify DTLS-SRTP sessions
Send DTLS alert message if the system terminates the call because it does not support any of the SRTP protection profiles offered by the client.

Important ESBC behavior related to DTLS-SRTP includes:

If the peer’s DTLS certificate matches the peer’s a=fingerprint If the validation is successful, then the system stops the dtls-complete-timeout. If this validation fails, the system terminates the media session.
Whenever the dtls-complete-timeout expires, the system terminates the media session.
The system drops any SRTP/SRTCP packets it receives before it has processed the DTLS-SRTP keys.
The system rejects an SDP media session offer that includes "a=fingerprint" but does not include the a=setup attribute.
The system must have a dtls-srtp-profile on any realm that must be able to process or generate an SDP offer for DTLS-SRTP. For example, if there is no profile at the ingress, the system rejects the request with a 503, service unavailable message.
The system provides both ingress and egress interworking support between DTLS-SRTP and RTP or SDES-SRTP.

Within the context of the DTLS setup procedure, the ESBC utilizes the following over the specified paths:

Signaling Path
- Recognizing and signaling the use of DTLS in the SDP m-line over the signaling path by the parameter "UDP/ TLS/RTP/SAVP"
- Specifying the server role to setup the media path using in "a=setup:passive" SDP
- Presenting the fingerprint of the end station in the SDP a=fingerprint line
- Specifying the media path using the IP address and the port exchanged in the offer/answer SDP in the “c=” and “m=” lines
Media Path
- Specifying the use of DTLS-SRTP with the use_srtp extension
- Providing its certificate for verification within the Hello exchange
- Using the cipher suite negotiated in the client and server Hello exchange to encrypt/decrypt the handshake messaging
- Complying with DTLS requirement for mutual authentication
- Using the negotiated encryption and decryption keys to encrypt/decrypt the media

The ESBC supports the following SRTP encryption and authentication algorithms using the DTLS-SRTP protection profiles defined in RFC 5764:

AES_CM_128_HMAC_SHA1_80 — Using the SRTP_AES128_CM_HMAC_SHA1_80 profile
AES_CM_128_HMAC_SHA1_32 — Using the SRTP_AES128_CM_HMAC_SHA1_32 profile

Configuring DTLS-SRTP

You configure DTLS-SRTP on the ESBC by setting up dtls-srtp-profile sub-element, within media-security.

dtls-srtp-profile configuration includes:

name—The name of this profile, which you enter to the dtls-srtp-profile parameter on a realm-config.
```
ORACLE(dtls-srtp-profile)#name MyDtlsProfile
```
tls-profile—The name of the tls-profile profile you use within this dtls-srtp-profile.
On each realm that has a configured dtls-srtp-profile, the ESBC includes the session attribute a=fingerprint in SDP offers. This fingerprint is the output of a hash function calculated over the certificate that the ESBC presents during the DTLS handshake. You configure this certificate within a tls-profile and apply it to the dtls-srtp-profile.

Note:
This session-level fingerprint attribute applies to both audio and video sessions for this realm, used when the ESBC functions as an offerer and answerer for both DTLS connections.
dtls-completion-timeout—Compliant with RFC 6347, this timeout establishes the time for the full DTLS handshake completion, consolidating timeouts for all the handshake messages. The ESBC starts this timer when it receives an answer SDP from the callee, and before sending an answer back to the caller. If the DTLS handshake is completed successfully within the configured dtls-completion-timeout value, the ESBC cancels the timer. If the DTLS handshake is not completed successfully within the timeout, the ESBC tears down the media flows as part of flow guard timer processing and clears the call by sending a BYE request to both legs.
The ESBC restarts this timer for any new DTLS association.
preferred-setup-role—Specifies the role the ESBC should perform for DTLS handshakes. The system only allows for the passive setting, which establishes itself as a server.
crypto-suite—Specifies the SRTP encryption and authentication algorithms the ESBC offers for this flow's media. This setting is not associated with the identity verification fingerprint.

After creating you profile, you apply it to the applicable realm-config.

ORACLE(realm-config)#dtls-srtp-profile MyDtlsProfile

Note:

This version of the ESBC requires successful rtcp-mux (RTCP multiplexing) negotiation during DTLS/SRP negotiations. As such, you must enable the dtls-srtp-profile parameter on each realm for which you have configured a dtls-srtp-profile.

ORACLE(realm-config)#rtcp-mux enabled

The ESBC does not support non-rtcp-mux flows and rejects calls that do not include successful rtcp-mux negotiation.

Related Configuration

Related configuration that impacts DTLS operation includes:

When you need different SRTP B2BUA termination by the system on both ingress and egress realms, such as SDES-SRTP and DTLS-SRTP on opposite sides, you must configure a media-sec-policy on both the ingress and egress realms.
- For DTLS-SRTP at an ingress realm and SDES-SRTP at the egress realm, you must configure an applicable media-sec-policy and a dtls-srtp-profile on the ingress realm. In addition:
  - Ingress media-sec-policy—Set mode to any and protocol set to none
  - Egress media-sec-policy—Set mode to srtp, and protocol set to sdes.
- For SDES-SRTP at an ingress realm and DTLS-SRTP at the egress realm, you must configure an applicable media-sec-policy and a dtls-srtp-profile on the egress realm. In addition:
  - Ingress media-sec-policy—Set mode to srtp, and protocol set to sdes.
  - Egress media-sec-policy—Set mode to any and protocol set to none
- A media-sec-policy is not required when both sides are DTLS-SRTP.
If the ESBC receives an SDP answer with 2 m-lines that includes DTLS and any other protocol, such as SDES, for the same media type, it terminates the SIP session, clearing the call by sending BYE with reason header with cause code “488 Not Acceptable Here”.
If you configure SDES on a realm, the ESBC always includes the session attribute a=crypto in the SDP offer it sends.
The ESBC accepts only DTLS messages for the port number on which it advertises SRTP/SRTCP for media flows that:
- had DTLS offered by the peer
- had DTLS accepted by the peer
- the ESBC has offered DTLS has but has not yet received an SDP answer