6.2.10 IMS end-to-access-edge Media Plane Security

23.3343GPPIP Multimedia Subsystem (IMS) Application Level Gateway (IMS-ALG) - IMS Access Gateway (IMS-AGW) interface: Procedures descriptionsRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.2.10.1 General

All message sequence charts in this clause are examples.

The H.248 context model is defined in Figure 6.2.1.1.

6.2.10.2 End-to-access-edge security for RTP based media using SDES

This procedure is identical to that of clause 6.2.1 apart from the IMS-ALG optionally requesting the IMS-AGW to provide IMS media plane security in accordance with 3GPP TS 33.328 [12].

The IMS-ALG shall provide the following media plane security related parameters to the IMS-AGW:

– the SDES crypto attributes

6.2.10.3 End-to-access-edge security for TCP-based media using TLS

6.2.10.3.1 End-to-access-edge security for session based messaging (MSRP)

6.2.10.3.1.1 IMS UE originating procedures for e2ae

6.2.10.3.1.1.1 Incoming TCP bearer establishment triggers an outgoing TCP bearer establishment

Figure 6.2.10.3.1.1.1.1 shows an example call flow for the originating session set-up procedures for one MSRP media stream using e2ae security, where an incoming TCP bearer establishment triggers an outgoing TCP bearer establishment.

Figure 6.2.10.3.1.1.1.1: Originating example call flow for e2ae security for MSRP where an incoming TCP bearer establishment triggers an outgoing TCP bearer establishment

The IMS UE A performs an IMS originating session set-up according to 3GPP TS 23.228 [2], with modifications as described in 3GPP TS 33.328 [12].

The procedure in the above figure for requesting e2ae security for a media stream is described step-by-step with an emphasis on the additional aspects for IMS-ALG and IMS-AGW of media protection using TLS.

1. IMS UE A sends an SDP offer for a media stream containing cryptographic information, together with an "a=3ge2ae:requested" SDP attribute for the MSRP-related SDP m-line, to the P‑CSCF (IMS‑ALG). For e2ae protection of MSRP the cryptographic information contained in the SDP offer consists of the fingerprint of the certificate of IMS UE A in accordance to IETF RFC 4975 [25]. For each media stream that uses transport "TCP/TLS/MSRP", the P‑CSCF (IMS‑ALG) checks for the presence of the "a=3ge2ae:requested" SDP attribute. If that indication is present and the P‑CSCF (IMS‑ALG) indicated support of e2ae-security for MSRP during registration, the P‑CSCF (IMS‑ALG) allocates the required resources, includes the IMS‑AGW in the media path and proceeds as specified in this clause.

NOTE 1: An operator can choose to terminate TLS in the IMS‑AGW according to the following steps for all media streams that are signalled in SIP INVITE messages with transport TCP/TLS/MSRP and a certificate fingerprint attribute, even if the UE did not indicate support for e2ae security during registration and did not indicate usage of e2ae security for the respective media streams in the INVITE. This can lead to session failures for pre-Rel-12 IMS UEs or non-IMS UEs due to a mismatch of security parameters sent by the network and expected by the UE, but on the other hand, it will ensure compatibility with GSMA RCS 5.1 [35, 36], which specifies that TLS for MSRP is always terminated in the network.

2.-4. The IMS-ALG uses the "Reserve AGW Connection Point" procedure to request a termination for "TCP" media (for application-agnostic interworking) or "TCP/MSRP" media (for application-aware interworking) towards the core network. To indicate that the IMS-AGW shall operate in TCP Proxy mode, the IMS-ALG provides "a=setup:actpass" attribute. The IMS-ALG sets the interlinkage topology on the termination T2 to configure the IMS-AGW to use the TCP connection establishment request (TCP SYN) received at the termination T2 as a trigger to send a TCP connection establishment on the termination T1.

NOTE 2: If "a=setup:passive" is received in the SDP answer in step 12, the IMS-ALG then needs to set the interlinkage topology on the termination T1 (not depicted).

5.-7. The IMS-ALG uses the "Reserve And Configure AGW Connection Point" procedure to request a termination for "TCP/TLS" media (for application-agnostic interworking) or "TCP/TLS/MSRP" media (for application-aware interworking) towards the access network. In the remote descriptor, it provides the IP address, port and fingerprint attribute received from the UE containing the fingerprint of the UE´s certificate in accordance to IETF RFC 4975 [25]. This instructs the IMS‑AGW to verify during the subsequent TLS handshake with the IMS UE that the fingerprint of the certificate passed by the IMS UE during this TLS handshake matches the fingerprint passed by the P‑CSCF (IMS‑ALG) to the IMS‑AGW. In turn, the IMS‑AGW communicates the fingerprint of the certificate it is going to use for setting up protection for this media stream to the P‑CSCF (IMS‑ALG). To indicate that the IMS-AGW shall operate in TCP Proxy mode, the IMS-ALG provides "a=setup:actpass" attribute.

NOTE 3: These steps could be combined with steps 16.-18. This saves H.248 signalling interactions but can delay the TCP connection setup.

8. The P‑CSCF (IMS‑ALG) changes the transport from "TCP/TLS/MSRP" to "TCP/MSRP" in the SDP offer, removes the "a=3ge2ae:requested" SDP attribute and the fingerprint SDP attribute, and inserts the address information received from the IMS-AGW.

9. The P‑CSCF (IMS‑ALG) forwards the SDP offer.

10. The remote peer chooses to become the active party in the TCP connection establishment and sends a TCP SYN to establish the TCP connection. If the P-CSCF (IMS-ALG) indicated to the IMS-AGW at step 2 that it shall ignore any incoming TCP connection establishment requests (TCP SYN), e.g. to enable a remote source transport address filtering, or if the P-CSCF (IMS-ALG) did not indicate to the IMS-AGW at step 2 that it shall latch onto the required destination address via the source address/port of the incoming media, the IMS-AGW shall drop the TCP SYN received from the remote peer.
If the TCP SYN is not answered before a timer expiry, the remote peer will send the TCP SYN a second time (step 10′). The IMS‑AGW will answer a repeated TCP SYN if it is received after step 13 (step 10′).
The IMS-AGW answers the TCP SYN and the remote peer completes the TCP connection establishment.

11. The IMS-AGW uses the TCP SYN received at the termination T2 (at step 10 or step 10′ if the TCP SYN is dropped at step 10) as a trigger to send a TCP SYN towards the UE to establish a TCP connection (effectively making the IMS-AGW acting as the TCP client towards the UE).. The UE answers the TCP SYN and the IMS-AGW completes the TCP connection establishment.

12. The P‑CSCF (IMS‑ALG) receives the SDP answer.

13.-15. The IMS-ALG uses the "Configure AGW Connection Point" procedure to configure the termination towards the core network with remote address information. If the P-CSCF (IMS-ALG) indicated to the IMS-AGW at step 2 that it shall ignore any incoming TCP connection establishment requests (TCP SYN), the IMS-ALG indicates to the IMS-AGW to accept incoming TCP connection establishment (TCP SYN) only from the indicated remote transport address.

NOTE 4: For "a=setup:active" in the SDP answer, these steps could possibly be skipped if the P-CSCF (IMS-ALG) indicated to the IMS-AGW at step 2 that it shall latch onto the required destination address via the source address/port of the incoming media, as the IMS-AGW will then use the address information in the TCP SYN when replying.

16.-18. The IMS-ALG uses the "Configure AGW Connection Point" procedure to configure the termination towards the access network with the request to establish the TLS session once the TCP connection is established (effectively making the IMS-AGW acting as the TLS client), in accordance with the information in the "a=setup" attribute in the SDP answer.

19. The P‑CSCF (IMS‑ALG) modifies the SDP answer before sending it to the UE A. The P‑CSCF (IMS‑ALG) sets the transport to "TCP/TLS/MSRP" and includes the fingerprint of the IMS‑AGW´s certificate in accordance to IETF RFC 4975 [25].

20. The P-CSCF (IMA-ALG) then sends the updated SDP answer to IMS UE A. After receiving this message IMS UE A completes the media security setup.

21. Upon completion of the TCP connection establishment, the IMS-AGW starts the establishment of the TLS session.

6.2.10.3.1.1.2 IMS-ALG requests sending an outgoing TCP bearer establishment

Figure 6.2.10.3.1.1.2.1 shows an example call flow for the originating session set-up procedures for one MSRP media stream using e2ae security, where the IMS-ALG requests sending an outgoing TCP bearer establishment.

Figure 6.2.10.3.1.1.2.1: Originating example call flow for e2ae security for MSRP where the IMS-ALG requests sending an outgoing TCP bearer establishment

The IMS UE A performs an IMS originating session set-up according to 3GPP TS 23.228 [2], with modifications as described in 3GPP TS 33.328 [12].

1. As step 1 in figure 6.2.10.3.1.1.1.1.

2.-4. As steps 2-4 in figure 6.2.10.3.1.1.1.1 with the exception that the IMS-ALG does not set the interlinkage topology on the termination T2.

5.-7. As steps 5-7 in figure 6.2.10.3.1.1.1.1.

8. As step 8 in figure 6.2.10.3.1.1.1.1.

9. As step 9 in figure 6.2.10.3.1.1.1.1.

10. As step 10 in figure 6.2.10.3.1.1.1.1.

NOTE: The incoming TCP SYN does not trigger the sending of an outgoing TCP SYN, and step 11 in figure 6.2.10.3.1.1.1.1thus does not apply.

11. As step 12 in figure 6.2.10.3.1.1.1.1.

12.-14. As steps 13-15 in figure 6.2.10.3.1.1.1.1.

15.-17. As steps 16-18 in figure 6.2.10.3.1.1.1.1with the exception that the IMS-ALG uses the "Configure AGW Connection Point" procedure also to configure the termination towards the access network with the request to establish the TCP connection (effectively making the IMS-AGW acting as the TCP client), in accordance with the information in the "a=setup" attribute in the SDP answer.

18. The IMS-AGW sends a TCP SYN towards the UE to establish a TCP connection. The UE answers with a TCP SYN ACK and the IMS‑AGW replies with a TCP ACK, completing the TCP connection establishment.

19. As step 21 in figure 6.2.10.3.1.1.1.1.

20. As step 19 in figure 6.2.10.3.1.1.1.1.

21. As step 20 in figure 6.2.10.3.1.1.1.1.

6.2.10.3.1.2 IMS UE terminating procedures for e2ae

6.2.10.3.1.2.1 Incoming TCP bearer establishment triggers an outgoing TCP bearer establishment

Figure 6.2.10.3.1.2.1.1 shows an example call flow for the terminating session set-up procedures for one MSRP media stream using e2ae security, where an incoming TCP bearer establishment triggers an outgoing TCP bearer establishment.

Figure 6.2.10.3.1.2.1.1: Terminating example call flow for e2ae security for MSRP where an incoming TCP bearer establishment triggers an outgoing TCP bearer establishment

The IMS UE B performs an IMS terminating session set-up according to 3GPP TS 23.228 [2], with modifications as described in 3GPP TS 33.328 [12].

1. The P‑CSCF (IMS‑ALG) receives an SDP offer for an MSRP media stream. For each MSRP media stream offered with transport "TCP/MSRP", if both the IMS UE and P‑CSCF (IMS‑ALG) indicated support for e2ae-security for MSRP during registration, the P‑CSCF (IMS‑ALG) allocates the required resources, includes the IMS‑AGW in the media path and proceeds as specified in this clause.

NOTE 1: An operator can choose to terminate TLS in the IMS‑AGW according to the following steps for all media streams that are signalled in SIP INVITE messages with transport TCP/MSRP, even if the UE did not indicate support for e2ae security during registration. This can lead to session failures for pre-Rel-12 IMS UEs or non-IMS UEs due to a mismatch of security parameters sent by the network and expected by the UE, but on the other hand, it will ensure compatibility with GSMA RCS 5.1 [35, 36], which recommends to always use e2ae security for MSRP on the terminating leg.

2.-4. The IMS-ALG uses the "Reserve AGW Connection Point" procedure to request a termination for "TCP/TLS" media (for application-agnostic interworking) or "TCP/TLS/MSRP" media (for application-aware interworking) towards the access network. In turn, the IMS‑AGW communicates the fingerprint of the certificate it is going to use for setting up protection for this media stream to the P‑CSCF (IMS‑ALG). To indicate that the IMS-AGW shall operate in TCP Proxy mode, the IMS-ALG provides "a=setup:actpass" attribute. The IMS-ALG sets the interlinkage topology on the termination T1 to configure the IMS-AGW to use the TCP connection establishment request (TCP SYN) received at the termination T1 as a trigger to send a TCP connection establishment on the termination T2.

NOTE 2: If "a=setup:passive" is received in the SDP answer in step 13, the IMS-ALG then needs to sets the interlinkage topology on the termination T2 (not depicted)

5.-7. The IMS-ALG uses the "Reserve And Configure AGW Connection Point" procedure to request a termination for "TCP" media (for application-agnostic interworking) or "TCP/ MSRP" media (for application-aware interworking) towards the core network. To indicate that the IMS-AGW shall operate in TCP Proxy mode, the IMS-ALG provides "a=setup:actpass" attribute.

8. The P‑CSCF (IMS‑ALG) changes the transport from "TCP/ MSRP" to "TCP/TLS/MSRP" in the SDP offer, adds the "a=3ge2ae:applied" SDP attribute and the fingerprint SDP attribute received from the IMS-AGW, and inserts the address information received from the IMS-AGW.

9. The P‑CSCF (IMS‑ALG) forwards the SDP offer.

10. The UE B chooses to become the active party in the TCP connection establishment and sends a TCP SYN to establish the TCP connection. If the P-CSCF (IMS-ALG) indicated to the IMS-AGW at step 2 that it shall ignore any incoming TCP connection establishment requests (TCP SYN), e.g. to enable a remote source transport address filtering, or if the P-CSCF (IMS-ALG) did not indicate to the IMS-AGW at step 2 that it shall latch onto the required destination address via the source address/port of the incoming media, the IMS-AGW shall drop the TCP SYN received from the UE.
If the TCP SYN is not answered before a timer expiry, the UE will send the TCP SYN a second time (step 10′). The IMS‑AGW will answer a repeated TCP SYN if it is received after step 14 (step 10′).
The IMS-AGW answers the TCP SYN and the remote peer completes the TCP connection establishment.

11. The IMS-AGW uses the TCP SYN received at the termination T1 (at step 10 or step 10′ if the TCP SYN is dropped at step 10) as a trigger to send a TCP SYN towards the core network to establish a TCP connection (effectively making the IMS-AGW acting as the TCP client towards the core network). The remote peer answers the TCP SYN and the IMS-AGW completes the TCP connection establishment.

12. Upon completion of the TCP connection establishment, the UE B starts the establishment of the TLS session. The IMS-AGW needs to wait until step 14 to verify the received fingerprint.

13. The P‑CSCF (IMS‑ALG) receives the SDP answer. It contains the fingerprint attribute with the UE´s certificate in accordance to IETF RFC 4975 [25].

14.-16. The IMS-ALG uses the "Configure AGW Connection Point" procedure to configure the termination towards the UE B with remote address information. In the remote descriptor, it also provides fingerprint attribute received from the UE. This instructs the IMS‑AGW to verify during the subsequent TLS handshake with the IMS UE that the fingerprint of the certificate passed by the IMS UE during this TLS handshake matches the fingerprint passed by the P‑CSCF (IMS‑ALG) to the IMS‑AGW. If the P-CSCF (IMS-ALG) indicated to the IMS-AGW at step 2 that it shall ignore any incoming TCP connection establishment requests (TCP SYN), the IMS-ALG indicates to the IMS-AGW to accept incoming TCP connection establishment (TCP SYN) only from the indicated remote transport address.

17. The P‑CSCF (IMS‑ALG) modifies the SDP answer before sending it to the core network. The P‑CSCF (IMS‑ALG) sets the transport to "TCP/ MSRP" and removes the SDP fingerprint attribute.

18. The P-CSCF (IMA-ALG) then sends the updated SDP answer to core network.

6.2.10.3.1.2.2 IMS-ALG requests sending an outgoing TCP bearer establishment

Figure 6.2.10.3.1.2.2.1 shows an example call flow for the terminating session set-up procedures for one MSRP media stream using e2ae security, where the IMS-ALG requests sending an outgoing TCP bearer establishment.

Figure 6.2.10.3.1.2.2.1: Terminating example call flow for e2ae security for MSRP where the IMS-ALG requests sending an outgoing TCP bearer establishment

The IMS UE B performs an IMS terminating session set-up according to 3GPP TS 23.228 [2], with modifications as described in 3GPP TS 33.328 [12].

1. As step 1 in figure 6.2.10.3.1.2.1.1.

2.-4. As steps 2-4 in figure 6.2.10.3.1.2.1.1 with the exception that the IMS-ALG does not set the interlinkage topology on the termination T1.

5.-7. As steps 7-7 in figure 6.2.10.3.1.2.1.1.

8. As step 8 in figure 6.2.10.3.1.2.1.1.

9. As step 9 in figure 6.2.10.3.1.2.1.1.

10. As step 10 in figure 6.2.10.3.1.2.1.1.

NOTE: The incoming TCP SYN does not trigger the sending of an outgoing TCP SYN, and step 11 in figure 6.2.10.3.1.2.1.1 thus does not apply.

11. As step 12 in figure 6.2.10.3.1.2.1.1.

12. As step 13 in figure 6.2.10.3.1.2.1.1.

13.-15. As steps 14-16 in figure 6.2.10.3.1.2.1.1.

16.-18. The IMS-ALG uses the "Configure AGW Connection Point" procedure to configure the termination towards the core network with the request to establish the TCP connection, in accordance with the information in the "a=setup" attribute in the SDP answer.

19. The IMS-AGW sends a TCP SYN towards the core network to establish a TCP connection. The remote peer answers with a TCP SYN ACK and the IMS‑AGW replies with a TCP ACK, completing the TCP connection establishment.

20. As step 17 in figure 6.2.10.3.1.2.1.1.

21. As step 18 in figure 6.2.10.3.1.2.1.1.

6.2.10.3.2 End-to-access-edge security for conferencing (BFCP)

6.2.10.3.2.1 IMS UE originating procedures for e2ae

6.2.10.3.2.1.1 Incoming TCP bearer establishment triggers an outgoing TCP bearer establishment

Figure 6.2.10.3.2.1.1.1 shows the originating session set-up procedures for one or more BFCP media stream(s) using e2ae security.

Figure 6.2.10.3.2.1.1.1: Originating example call flow for e2ae security for BFCP where an incoming TCP bearer establishment triggers an outgoing TCP bearer establishment

The IMS UE A performs an IMS originating session set-up according to 3GPP TS 23.228 [2], with modifications as described in 3GPP TS 33.328 [12].

1. IMS UE A sends an SDP offer for a media stream containing cryptographic information, together with an "a=3ge2ae:requested" SDP attribute for the BFCP-related SDP m-line, to the P‑CSCF (IMS‑ALG). For e2ae protection of BFCP the cryptographic information contained in the SDP offer consists of the fingerprint of the certificate of IMS UE A in accordance to IETF RFC 4975 [25]. For each media stream that uses transport "TCP/TLS/BFCP", the P‑CSCF (IMS‑ALG) checks for the presence of the "a=3ge2ae:requested" SDP attribute. If that indication is present and the P‑CSCF (IMS‑ALG) indicated support of e2ae-security for BFCP during registration, the P‑CSCF (IMS‑ALG) allocates the required resources, includes the IMS‑AGW in the media path and proceeds as specified in this clause.

2.-4. The IMS-ALG uses the "Reserve AGW Connection Point" procedure to request a termination for "TCP" media towards the core network. To indicate that the IMS-AGW shall operate in TCP Proxy mode, the IMS-ALG provides "a=setup:actpass" attribute. The IMS-ALG sets the interlinkage topology on the termination T2 to configure the IMS-AGW to use the TCP connection establishment request (TCP SYN) received at the termination T2 as a trigger to send a TCP connection establishment on the termination T1.

NOTE 1: If "a=setup:passive" is received in the SDP answer in step 13, the IMS-ALG then needs to set the interlinkage topology on the termination T1 (not depicted).

5.-7. The IMS-ALG uses the "Reserve And Configure AGW Connection Point" procedure to request a termination for "TCP/TLS" media towards the access network. In the remote descriptor, it provides the IP address, port and fingerprint attribute received from the UE containing the fingerprint of the UE´s certificate in accordance to IETF RFC 4975 [25]. This instructs the IMS‑AGW to verify during the subsequent TLS handshake with the IMS UE that the fingerprint of the certificate passed by the IMS UE during this TLS handshake matches the fingerprint passed by the P‑CSCF (IMS‑ALG) to the IMS‑AGW. In turn, the IMS‑AGW communicates the fingerprint of the certificate it is going to use for setting up protection for this media stream to the P‑CSCF (IMS‑ALG). To indicate that the IMS-AGW shall operate in TCP Proxy mode, the IMS-ALG provides "a=setup:actpass" attribute.

8. The P‑CSCF (IMS‑ALG) changes the transport from "TCP/TLS/BFCP" to "TCP/BFCP" in the SDP offer, removes the "a=3ge2ae:requested" SDP attribute and the fingerprint SDP attribute, and inserts the address information received from the IMS-AGW.

9. The P‑CSCF (IMS‑ALG) forwards the SDP offer.

10. The remote peer chooses to become the active party in the TCP connection establishment and sends a TCP SYN to establish the TCP connection. If the P-CSCF (IMS-ALG) indicated to the IMS-AGW at step 2 that it shall ignore any incoming TCP connection establishment requests (TCP SYN), e.g. to enable a remote source transport address filtering, or if the P-CSCF (IMS-ALG) did not indicate to the IMS-AGW at step 2 that it shall latch onto the required destination address via the source address/port of the incoming media, the IMS-AGW shall drop the TCP SYN received from the remote peer.
If the TCP SYN is not answered before a timer expiry, the remote peer will send the TCP SYN a second time (step 10′). The IMS‑AGW will answer a repeated TCP SYN if it is received after step 14 (step 10′).
The IMS-AGW answers the TCP SYN and the remote peer completes the TCP connection establishment.

11. The IMS-AGW uses the TCP SYN received at the termination T2 (at step 10 or step 10′ if the TCP SYN is dropped at step 10) as a trigger to send a TCP SYN towards the UE to establish a TCP connection (effectively making the IMS-AGW acting as the TCP client towards the UE). The UE answers the TCP SYN and the IMS-AGW completes the TCP connection establishment.

12. Upon completion of the TCP connection establishment, the UE B starts the establishment of the TLS session. The IMS-AGW needs to wait until step 14 to verify the received fingerprint.

13. The P‑CSCF (IMS‑ALG) receives the SDP answer.

14.-16. The IMS-ALG uses the "Configure AGW Connection Point" procedure to configure the termination towards the core network with remote address information. If the P-CSCF (IMS-ALG) indicated to the IMS-AGW at step 2 that it shall ignore any incoming TCP connection establishment requests (TCP SYN), the IMS-ALG indicates to the IMS-AGW to accept incoming TCP connection establishment (TCP SYN) only from the indicated remote transport address.

NOTE 2: For "a=setup:active" in the SDP answer, these steps could possibly be skipped if the P-CSCF (IMS-ALG) indicated to the IMS-AGW at step 2 that it shall latch onto the required destination address via the source address/port of the incoming media, as the IMS-AGW will then use the address information in the TCP SYN when replying.

17. The P‑CSCF (IMS‑ALG) modifies the SDP answer before sending it to the UE A. The P‑CSCF (IMS‑ALG) sets the transport to "TCP/TLS/BFCP" and includes the fingerprint of the IMS‑AGW´s certificate in accordance to IETF RFC 4975 [25].

18. The P-CSCF (IMA-ALG) then sends the updated SDP answer to IMS UE A. After receiving this message IMS UE A completes the media security setup.

6.2.10.3.2.2 IMS UE terminating procedures for e2ae

6.2.10.3.2.2.1 Incoming TCP bearer establishment triggers an outgoing TCP bearer establishment

Figure 6.2.10.3.2.2.1.1 shows the terminating session set-up procedures for one or more BFCP media stream(s) using e2ae security.

Figure 6.2.10.3.2.2.1.1: Terminating example call flow for e2ae security for MSRP where an incoming TCP bearer establishment triggers an outgoing TCP bearer establishment

The IMS UE B performs an IMS terminating session set-up according to 3GPP TS 23.228 [2], with modifications as described in 3GPP TS 33.328 [12].

1. The P‑CSCF (IMS‑ALG) receives an SDP offer for an MSRP media stream. For each BFCP media stream offered with transport "TCP/BFCP", if both the IMS UE and P‑CSCF (IMS‑ALG) indicated support for e2ae-security for BFCP during registration, the P‑CSCF (IMS‑ALG) allocates the required resources, includes the IMS‑AGW in the media path and proceeds as specified in this clause.

2.-4. The IMS-ALG uses the "Reserve AGW Connection Point" procedure to request a termination for "TCP/TLS" media towards the access network. The IMS-ALG configures the IMS-AGW with the request to start the establishment of the TLS session once the TCP connection is established (effectively making the IMS-AGW acting as the TLS client). . To indicate that the IMS-AGW shall operate in TCP Proxy mode, the IMS-ALG provides "a=setup:actpass" attribute. The IMS-ALG sets the interlinkage topology on the termination T1 to configure the IMS-AGW to use the TCP connection establishment request (TCP SYN) received at the termination T1 as a trigger to send a TCP connection establishment on the termination T2.
The IMS‑AGW communicates the fingerprint of the certificate it is going to use for setting up protection for this media stream to the P‑CSCF (IMS‑ALG).

NOTE: If "a=setup:passive" is received in the SDP answer in step 13, the IMS-ALG then needs to sets the interlinkage topology on the termination T2 (not depicted)

5.-7. The IMS-ALG uses the "Reserve And Configure AGW Connection Point" procedure to request a termination for "TCP" media towards the core network. To indicate that the IMS-AGW shall operate in TCP Proxy mode, the IMS-ALG provides "a=setup:actpass" attribute.

8. The P‑CSCF (IMS‑ALG) changes the transport from "TCP/ BFCP" to "TCP/TLS/BFCP" in the SDP offer, adds the "a=3ge2ae:applied" SDP attribute and the fingerprint SDP attribute received from the IMS-AGW, and inserts the address information received from the IMS-AGW.

9. The P‑CSCF (IMS‑ALG) forwards the SDP offer.

11. The IMS-AGW sends a TCP SYN towards the core network to establish a TCP connection. The remote peer answers the TCP SYN and the IMS-AGW completes the TCP connection establishment.

12. Upon completion of the TCP connection establishment, the IMS-AGW starts the establishment of the TLS session. The IMS-AGW needs to wait until step 14 to verify the received fingerprint.

13. The P‑CSCF (IMS‑ALG) receives the SDP answer. It contains the fingerprint attribute with the UE´s certificate in accordance to IETF RFC 4975 [25].

14.-16. The IMS-ALG uses the "Configure AGW Connection Point" procedure to configure the termination towards the UE B with remote address information. In the remote descriptor, it also provides fingerprint attribute received from the UE. This instructs the IMS‑AGW to verify during the TLS handshake with the IMS UE (see step 12) that the fingerprint of the certificate passed by the IMS UE during this TLS handshake matches the fingerprint passed by the P‑CSCF (IMS‑ALG) to the IMS‑AGW. If the P-CSCF (IMS-ALG) indicated to the IMS-AGW at step 2 that it shall ignore any incoming TCP connection establishment requests (TCP SYN), the IMS-ALG indicates to the IMS-AGW to accept incoming TCP connection establishment (TCP SYN) only from the indicated remote transport address.

17. The P‑CSCF (IMS‑ALG) modifies the SDP answer before sending it to the core network. The P‑CSCF (IMS‑ALG) sets the transport to "TCP/ BFCP" and removes the SDP fingerprint attribute.

18. The P‑CSCF (IMS‑ALG) then sends the updated SDP answer to core network.

6.2.10.4 End-to-access-edge security for UDP based media using DTLS

6.2.10.4.1 General

The IMS-ALG and the IMS-AGW may support e2ae security for the UDP based media using DTLS and certificate fingerprints.

The following clauses describe extensions to the Iq signalling procedures and their interactions with SIP signalling in the control plane and with user plane procedures if the e2ae security for the UDP based media using DTLS and certificate fingerprints is supported by the IMS-ALG and the IMS-AGW and if the IMS-ALG indicated support of e2ae security for the UDPTL using DTLS and certificate fingerprints during registration.

6.2.10.4.2 Session establishment from IMS access network for T.38 fax using "UDP/TLS/UDPTL"

Upon receipt of an SDP offer from the IMS access network containing T.38 fax media using the "UDP/TLS/UDPTL" transport protocol with the associated:

– 3ge2ae SDP attribute, as defined in 3GPP TS 24.229 [11], with a value "requested";

– fingerprint SDP attribute(s) as defined in IETF RFC 8122 [80];

– DTLS association identity SDP attribute "a=tls-id" defined in IETF RFC 8842 [81]; and

– setup SDP attribute as defined in IETF RFC 4145 [30];

the IMS-ALG shall:

– check the received value of the setup SDP attribute to determine if the IMS-AGW needs to act as DTLS client or DTLS server. When the received value is equal to:

a) "active" the IMS-AGW needs to act as DTLS server;

b) "passive" the IMS-AGW needs to act as DTLS client; or

c) "actpass" the IMS-ALG shall decide if the IMS-AGW needs to act as DTLS client or DTLS server;

– when reserving the transport addresses/resources towards the IMS access network:

a) indicate to the IMS-AGW "UDP/DTLS" as transport protocol;

b) if the IMS-AGW needs to act as DTLS client, include the Establish (D)TLS session information element to request the IMS-AGW to start the DTLS session setup;

c) include the Notify (D)TLS session establishment Failure Event information element to request the IMS-AGW to report the unsuccessful DTLS session setup;

d) include the Remote certificate fingerprint information element with the value of the received fingerprint SDP attribute(s); and

e) include the Local certificate fingerprint Request information element to request the certificate fingerprint of the IMS-AGW;

– indicate to the IMS-AGW "UDP" as transport protocol when reserving the transport addresses/resources towards the IMS core network; and

– remove the setup SDP attribute and indicate the transport protocol "UDPTL" in the SDP offer towards the IMS core network.

Upon receipt of an SDP answer from the IMS core network, the IMS-ALG shall:

– in the "m=" line indicating T.38 fax using UDPTL, change the transport protocol to "UDP/TLS/UDPTL";

– insert the fingerprint SDP attribute with the value of the Local certificate fingerprint information element received from the IMS-AGW;

– insert the "a=tls-id" SDP attribute containing a new DTLS association identity; and

– insert the setup SDP attribute with the value:

a) "active" if the IMS-ALG requested the IMS-AGW to act as DTLS client; or

b) "passive" if the IMS-AGW shall take the DTLS server role.

The message sequence chart shown in the figure 6.2.10.4.2.1 gives an example of a session establishment from the IMS access network with an emphasis on the additional aspects for the IMS-ALG and the IMS-AGW for the e2ae protection of the T.38 fax media using UDPTL over DTLS.

Figure 6.2.10.4.2.1: Session setup from the IMS access network with e2ae protection of T.38 fax

6.2.10.4.3 Session establishment towards IMS access network for T.38 fax using "UDP/TLS/UDPTL"

Upon receipt of an SDP offer from the IMS core network containing T.38 fax media using the "UDPTL" transport protocol the IMS-ALG shall:

– when reserving the transport addresses/resources towards the IMS access network:

a) indicate to the IMS-AGW "UDP/DTLS" as transport protocol;

b) include the Notify (D)TLS session establishment Failure Event information element to request the IMS-AGW to report the unsuccessful DTLS session setup; and

NOTE 1: The IMS-ALG may omit this information element when reserving resources and instead send it to the IMS-AGW when modifying the resources towards the IMS access network.

c) include the Local certificate fingerprint Request information element to request the certificate fingerprint of the IMS-AGW; and

– when reserving the transport addresses/resources towards the IMS core network indicate to the IMS-AGW "UDP" as transport protocol.

– modify the SDP offer that will be sent to the IMS access network by:

– in the "m=" line indicating T.38 fax using UDPTL, changing the transport protocol to "UDP/TLS/UDPTL";

– inserting the 3ge2ae SDP attribute, as defined in 3GPP TS 24.229 [11], with a value "applied";

– inserting the fingerprint SDP attribute, as defined in IETF RFC 8122 [80], with the value of the Local certificate fingerprint information element received from the IMS-AGW;

– inserting the "tls-id" SDP attribute with the new DTLS association identity; and

– inserting the setup SDP attribute, as defined in IETF RFC 4145 [30], e.g. with the value "actpass".

NOTE 2: Alternatively, the IMS-ALG can set the value of the setup SDP attribute to "active" if the IMS-ALG wants that the IMS-AGW provides the DTLS client role or to "passive" if the IMS-ALG wants that the IMS-AGW provides the DTLS server role e.g. for NAT traversal.

Upon receipt of an SDP answer from the IMS access network containing T.38 fax media using the "UDP/TLS/UDPTL" transport protocol with the associated fingerprint and setup SDP attributes, the IMS-ALG shall:

– check the value of the received setup SDP attribute to determine if the IMS-AGW needs to act as DTLS client or DTLS server. When the received value is equal to:

a) "active" the IMS-AGW needs to act as DTLS server; or

b) "passive" the IMS-AGW needs to act as DTLS client;

– when modifying the transport addresses/resources towards the IMS access network:

a) if the IMS-AGW needs to act as DTLS client, include the Establish (D)TLS session information element to request the IMS-AGW to start the DTLS session setup;

b) include the Remote certificate fingerprint information element with the value of the received fingerprint SDP attribute(s); and

c) if not already provided, include the Notify (D)TLS session establishment Failure Event information element to request the IMS-AGW to report the unsuccessful DTLS session setup; and

– remove the setup SDP attribute and indicate the transport protocol "UDPTL" in the SDP answer sent towards the IMS core network.

The message sequence chart shown in the figure 6.2.10.4.3.1 gives an example of a session establishment towards the IMS access network with an emphasis on the additional aspects for the IMS-ALG and the IMS-AGW for the e2ae protection of the T.38 fax media using UDPTL over DTLS.

NOTE 3: In the shown example it is assumed that the IMS-ALG requested the IMS-AGW at step 2 to latch onto the address of the received media packets to determine the corresponding destination address. Otherwise, the DTLS ClientHello message received at the step 10 will be dropped until the IMS-AGW receives a repeated DTLS ClientHello message after the step 13.

Figure 6.2.10.4.3.1: Session setup towards the IMS access network with e2ae protection of T.38 fax

6.2.10.4.4 IMS-AGW procedure for e2ae security of T.38 fax using "UDP/TLS/UDPTL"

The IMS-AGW shall:

– upon reception of the Local certificate fingerprint Request information element, select an own certificate for the T.38 fax media stream, uniquely associate the own certificate with the T.38 media stream, and send to the IMS-ALG the Local certificate fingerprint information element with the fingerprint of the own certificate;

– uniquely associate the value of the Remote certificate fingerprint information element, received from the IMS-ALG, with the corresponding T.38 fax media stream;

– take a DTLS server role and be prepared to receive a DTLS ClientHello message from the served UE;

– upon reception of the Establish (D)TLS session information element, take a DTLS client role and start DTLS session establishment by sending the DTLS ClientHello message to the served UE; and

– verify during the subsequent DTLS handshake with the served UE (as described in IETF RFC 7345 [33] and IETF RFC 8842 [81]) that the fingerprint of the certificate passed by the served UE during DTLS handshake matches the value of the Remote certificate fingerprint information element received from the IMS-ALG:

a) if the verification fails, the IMS-AGW shall regard the remote DTLS endpoint as not authenticated, terminate the DTLS session and as specified in clause 6.2.10.4.5, shall report the unsuccessful DTLS session setup to the IMS-ALG; or

b) if the verification succeeds, the IMS-AGW shall continue with DTLS session setup and when the DTLS session is established, the IMS-AGW shall be prepared to receive and convert the protected media from the served UE to the unprotected media to be sent to the core network and vice versa.

6.2.10.4.5 DTLS session establishment failure indication

The IMS-AGW shall use a Notify (D)TLS session establishment Failure Indication procedure to report DTLS session establishment related failures.

The figure 6.2.10.4.5.1 shows the message sequence chart example when the IMS-AGW reports the unsuccessful DTLS session setup to the IMS-ALG.

Figure 6.2.10.4.5.1: DTLS session establishment failure indication

6.2.10.5 End-to-access-edge security for RTP based media using DTLS-SRTP

The procedures are similar to that of clause 6.2.1 apart from the IMS-ALG optionally requesting the eIMS-AGW to provide IMS media plane security using DTLS.

Upon receipt of an SDP offer from the IMS access network, the IMS-ALG shall:

– check the received value of the setup SDP attribute to determine if the IMS-AGW needs to act as DTLS client or DTLS server. When the received value is equal to:

a) "active" the IMS-AGW needs to act as DTLS server;

b) "passive" the IMS-AGW needs to act as DTLS client; or

c) "actpass" the IMS-ALG shall decide if the IMS-AGW needs to act as DTLS client or DTLS server;

– if the received SDP offer contains "a=tls-id" media-level SDP attribute (as specified in IETF RFC 8842 [81]), create a new DTLS association identity;

– when reserving the transport addresses/resources towards the IMS access network:

a) indicate to the IMS-AGW "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF" as transport protocol;

b) include the Remote certificate fingerprint information element with the value of the received fingerprint SDP attribute from the UE (IMS UE or WIC);

c) include the Local certificate fingerprint Request information element to request the certificate fingerprint of the IMS-AGW; and

d) if the IMS-AGW needs to act as DTLS client, include the Establish (D)TLS session information element to request the IMS-AGW to start the DTLS session setup;

– indicate to the IMS-AGW "RTP/AVP" or "RTP/AVPF" over UDP as transport protocol when reserving the transport addresses/resources towards the IMS core network; and

– remove the setup SDP attribute and indicate the transport protocol "RTP/AVP" in the offer towards the IMS core network.

Upon receipt of an SDP answer from the IMS core network, the IMS-ALG shall:

– in the "m=" line indicating the use of SRTP, change the transport protocol to "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF";

– insert the fingerprint SDP attribute with the value of the Local certificate fingerprint information element received from the IMS-AGW; and

– insert the "a=tls-id" SDP attribute containing a new DTLS association identity; and

– insert the setup SDP attribute with the value:

a) "active" if the IMS-ALG requested the IMS-AGW to act as DTLS client; or

b) "passive" if the IMS-AGW shall take the DTLS server role.

Figure 6.2.10.5.1 shows the message sequence chart example of UE (IMS UE or WIC) originated procedure using DTLS-SRTP.

NOTE 1: There are two served user instances of the DTLS service within WebRTC: the data channel and the key exchange for SRTP. Thus, there are either two DTLS connections behind a single DTLS session, or two separate DTLS sessions. Below establishment procedures when applied for WebRTC are based on the assumption that there wasn’t yet any DTLS procedure triggered from WebRTC data channel side.

Figure 6.2.10.5.1: UE originated procedure using DTLS-SRTP

NOTE 2: The UE (IMS UE or WIC) may receive the ClientHello prior the SDP answer, thus the handshake might be initiated, but the handshake will not complete until the SDP answer has been received by the UE (IMS UE or WIC).

Upon receipt of an SDP offer from the IMS core network using the "RTP/AVP" or "RTP/AVPF" over UDP as transport protocol the IMS-ALG shall:

– when reserving the transport addresses/resources towards the IMS access network:

a) indicate to the IMS-AGW "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF" as transport protocol; and

b) include the Local certificate fingerprint Request information element to request the certificate fingerprint of the IMS-AGW;

– when reserving the transport addresses/resources towards the IMS core network indicate to the IMS-AGW "RTP/AVP" or "RTP/AVPF" over UDP as transport protocol; and

– modify the SDP offer that will be sent to the IMS access network by:

a) in the "m=" line that is indicating the use of SRTP, changing the transport protocol to "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF";

b) inserting the fingerprint SDP attribute with the value of the Local certificate fingerprint information element received from the IMS-AGW;

c) inserting the "tls-id" SDP attribute with the new DTLS association identity; and

d) inserting the setup SDP attribute, as defined in IETF RFC 4145 [30], with the value "actpass".

Upon receipt of an SDP answer from the IMS access network containing the use of the "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF" transport protocol with the associated fingerprint and setup SDP attributes, the IMS-ALG shall:

– check the value of the received setup SDP attribute to determine if the IMS-AGW needs to act as DTLS client or DTLS server. When the received value is equal to:

a) "active" the IMS-AGW needs to act as DTLS server; or

b) "passive" the IMS-AGW needs to act as DTLS client;

– when modifying the transport addresses/resources towards the IMS access network:

a) if the IMS-AGW needs to act as DTLS client, include the Establish (D)TLS session information element to request the IMS-AGW to start the DTLS session setup;

b) include the Remote certificate fingerprint information element with the value of the received fingerprint SDP attribute; and

c) if not already provided, include the Notify (D)TLS session establishment Failure Event information element to request the IMS-AGW to report the unsuccessful DTLS session setup; and

– remove the setup SDP attribute and indicate the transport protocol "RTP/AVP" in the SDP answer towards the IMS core network.

The message sequence chart shown in the figure 6.2.10.5.2 shows the message sequence chart example of UE (IMS UE or WIC) terminated procedure using DTLS-SRTP.

Figure 6.2.10.5.2: UE terminated procedure using DTLS-SRTP

NOTE 3: The IMS-AGW might receive the ClientHello prior receiving the MOD-request, but the DTLS handshake will not finish before the MOD-request (more specific: the fingerprint from UE (IMS UE-b or WIC-b) has been received.

6.2.10.6 End-to-access-edge security for WebRTC data channels using SCTP-over-DTLS transport

6.2.10.6.1 General

The requirements on eP-CSCF (IMS-ALG) and eIMS-AGW for the procedures to establish WebRTC data channels are specified in clause 5.20.2.

All message sequence charts in this clause are examples. The example high-level H.248 context model is defined in Figure 6.2.1.1 and further detailed below.

6.2.10.6.2 Call flow for data channel establishment from WIC towards IMS access network and MSRP session establishment

Support of multiple WebRTC data channels per WebRTC calls implies support of so called H.248 stream grouping. Figure 6.2.10.6.2.1 shows an example H.248 Context model for a WebRTC call with unbundled audio and video, and with multiple data components.

Figure 6.2.10.6.2.1: eIMS-AGW – H.248 Context model for WebRTC gateway inclusive H.248 Stream Group for WebRTC data components

The example flow in this clause focuses on the WebRTC data channel part only. Thus, only H.248 Streams S1 (for deaggregation of multiple data channels) and S2 (for MSRP traffic) are indicated subsequently.

Figure 6.2.10.6.2.2 shows the message sequence chart example for the WIC originated procedure to establish a WebRTC MSRP data channel using SCTP-over-DTLS transport.

Figure 6.2.10.6.2.2: WIC originated procedure for WebRTC data channel establishment and MSRP stream establishment

The IMS UE A embedded WIC-A performs an IMS originating session set-up according to 3GPP TS 23.228 [2] with modifications for support of WebRTC service control.

The procedure in the above figure for requesting an MSRP profiled WebRTC data channel is described step-by-step with an emphasis on the additional aspects for eP-CSCF (IMS-ALG) and eIMS-AGW with regards to the creation of an H.248 Context for interworking MSRP-over-DC to MSRP-over-TCP:

1. IMS UE-A (WIC-A) sends an SDP offer for an MSRP WebRTC data channel. A new "SCTP association over DTLS association " is requested.

2. – 4. The eP-CSCF (IMS-ALG) uses the "Reserve AGW Connection Point" procedure to request a termination and H.248 Stream ‘2’ for "MSRP-over-TCP" media towards the core network.

5. The eP‑CSCF (IMS‑ALG) modifies the SDP offer to offers TCP transport for MSRP, and to requests the remote peer to select the TCP setup direction.

6. The eP‑CSCF (IMS‑ALG) forwards the SDP offer.

7. – 10. The configuration of core network side H.248 Stream endpoint S₂/T₂ is completed based on the received SDP answer (7).

11. The eP-CSCF (IMS-ALG) uses the "Reserve and Configure AGW Connection Point" procedure to request a termination inclusive an H.248 Stream Group for WebRTC DC traffic. The eP-CSCF (IMS-ALG) uses an H.248 Context model with H.248 Stream grouping as required for WebRTC DC support. The Stream Group (SG) configurations according to Figure 6.2.10.6.2.1 is applied: The eP-CSCF (IMS-ALG) decides to assign H.248 StreamID value ‘1’ to the H.248 deaggregation stream and to use H.248 StreamID value ‘2’ for the WebRTC data channel. The following aspects should be emphasized:

a) H.248 deaggregation stream (S₁):
– covers the protocol stack segment "SCTP Association over DTLS connection over L4/IP";
– the ‘UDP’ is indicated as L4 protocol;
– the SDP information related to the underlying ICE procedures is omitted in the abstracted ADD.req command;
– the deaggregation stream embedded SDP covers the attributes for configuration of the SCTP Association;

b) H.248 component stream (S₂):
– covers the upper protocol levels of the logical DC and the IP application layer (here ‘MSRP’);

c) DTLS session/DTLS association establishment:
– an outgoing establishment procedure is enabled ("which will be executed by the eIMS-AGW after successful L4 connectivity");

d) SCTP association establishment:
– both, an incoming and outgoing establishment procedure is enabled ("in order to emulate "SCTP simultaneous open" behaviour");
– the eIMS-AGW would start to send an SCTP INIT chunk as soon as the DTLS connection is "data transfer ready" (see step 16);

e) Preparation of DC release already in DC establishment phase:
– Background: DC release is based on SCTP Association level SCTP Stream reset procedures. Incoming reset requests could be either autonomously handled by the eIMS-AGW or explicitly controlled by the eP-CSCF (IMS-ALG).
– The activation of a notification mechanism is required in any case (indicating the autonomous behaviour by the default value ‘accept’ of the correspondent event parameter).

12./13. The eIMS-AGW confirms the successful creation and configuration of the requested H.248 Stream Group for WebRTC DC traffic.

14./15. The eP-CSCF (IMS-ALG) then sends the updated SDP answer to the IMS UE-A embedded WIC-A.

NOTE: In figure 6.2.10.6.2.2. "a=dcmap" does not contain priority information and the default priority thus applies.