The SBC Core supports end-to-access edge security (e2ae) which involves media protection extending between an IMS UE and the first IMS core network node in the media path without being terminated by any intermediary. The e2ae mechanism secures only the access edge, and is not applicable for all hops. For media protection, SBC uses the existing SRTP mechanism.
When the UE indicates e2ae, and if SRTP is enabled on SBC, e2ae media security is applied.
The e2ae media security consists of:
Use "show status addressContext <address context name> sipActiveRegisterNameStatus
" command to view media-security status (e2aeMediaSecurity
) of the UE in the registration record. See Show Status Address Context for details.
The IMS UE implicitly authorizes the SBC (and the IMS Access GW) to perform e2ae security by indicating "sdes-srtp:mediasec" during the registration. The SBC includes "sdes-srtp:mediasec" in a response message to the IMS UE during registration, when SRTP is enabled in the trunk group. The IMS UE stores this indication to use it with originating session set-up procedures.
A request for e2ae security from an IMS UE is allowed only if both the IMS UE and SBC (IMS-ALG) have indicated support of e2ae security.
Example call flow:
mech-parameters =/ mediasec-param
mediasec-param = "mediasec"
The SBC supports “mediasec” header parameter in the Security-Client header field. During the registration response process, the SBC generates the mechanism-name “sdes-srtp:mediasec” (Security-Server, or Security-Verify headers). The SBC marks the e2ae-sdes-srtp supported indication in the registration record. Any other mechanisms specified by the UE is ignored.
If the registration from the IMS UE contains "sdes-srtp:mediasec" indication in the Security-Client header, SBC verifies whether SRTP is enabled for the packet service profile associated with that trunk group. If enabled, SBC inserts a Security-Server header containing the "sdes-srtp:mediasec" in the 200 OK response. If SRTP is not enabled, SBC does not include the "sdes-srtp:mediasec" header field in the Security-Server header.
A UE-A enables e2ae media security by sending "3ge2ae: requested" in the SDP. Once e2ae media security is successfully applied, the SBC includes "3ge2ae: applied" in the SDP.
On receipt of REGISTER message from UE, SBC forwards the REGISTER message modifying Security-Client header removing the ”sdes-srtp:mediasec” attribute.
While forwarding 200 OK to REGISTER message, if SRTP is enabled on the Trunk Group towards the UE, SBC indicates support for "sdes-srtp:mediasec" if this is received in REGISTER message. This decision is stored in RCB and is used while processing originating and terminating calls from or towards UE.
Example call flow:
If the subscriber’s registration record indicates e2ae-media-security supported and the ingress SDP contains “a=3ge2ae:requested” attribute and the crypto attributes, SBC terminates the SRTP stream locally and sends SDP answer containing “a=3ge2ae:applied” towards that UE with RTP/SAVP and RTP/SAVPF profiles.
If e2ae is not registered and requested in the SDP, and if SRTP parameters are present in the UE's SDP and SBC is configured to do SRTP, SBC will use SRTP without “a=3ge2ae:applied”
The SBC always terminates media if the e2ae media security is ON in subscriber registration record. The SBC includes “a=3ge2ae: applied” attribute along with the SRTP parameters in the SDP offer to the terminating UE.
If the subscriber record is enabled for e2ae media security, but SRTP is not configured in the PSP, SBC ignores the e2ae media security and proceeds with the call normally (This is possible if SRTP is disabled on the trunk group after subscriber registration). If the subscriber record does not have e2ae media security enabled, but SRTP is configured in the PSP, SBC uses SRTP towards the endpoint but omits the “a=3ge2ae: applied” in SDP offer.
If SBC is configured for SRTP on the Trunk Group, even if the UE is not registered for e2ae security, SBC would offer SRTP attributes in SDP but without “a=3ge2ae:applied”.