W.3 Service and Media Reachability for Users over Restrictive Firewalls – Extensions to STUN/TURN/ICE

33.2033G Security3GPPAccess security for IP-based servicesTS

Editor’s note: Details on the extensions (HTTP CONNECT and detection mechanism for determining firewall types and explicit mention of supporting TCP port 443) to STUN/TURN/ICE is ffs.

W.3.1 Introduction

W.3.1.1 General

This clause specifies a firewall traversal solution for IMS control and media traffic based on SIP over TLS and an extended version of the ICE protocol [ICE, ICE-TCP]. In this solution, the TLS profile as defined in TS 33.310 [24] shall be used.

The method is intended for IMS clients that are located behind IMS-unaware firewalls and which fail to perform IMS registration and/or session establishment using the normal procedures. The method is likely to succeed as long as the firewall permits HTTP(S) traffic and does not perform extensive traffic monitoring. The method consists of two sub-solutions, one for the IMS media plane and one for the IMS control plane.

Note that this solution is only applicable to UEs which already support the use of ICE as defined in Annex G of TS 23.228 [3].

W.3.1.2 Firewall traversal for IMS control plane using SIP over TLS/TCP

Firewall traversal for IMS control plane is accomplished by running SIP over TLS and using port 443 (HTTPS) instead of the standard port 5061 (SIPS). This makes the SIP signalling appear as HTTPS traffic to any firewall that is present along the signalling path.

In order to ensure that the firewall pinholes are maintained, the IMS client -shall apply the keep-alive mechanism specified in RFC 5626 [32]. The keep-alive mechanism is negotiated by the IMS client and the P-CSCF at IMS registration using the method described in RFC 6223 [64]. Note that RFC 5626 defines two keep-alive techniques: a technique based on STUN for connection-less transports and a technique based on SIP (called CRLF) for connection-oriented transports. Since TCP is used as transport between the IMS client and the P-CSCF, the CRLF keep-alive technique must be used.

In case the IMS client is configured to use an HTTP proxy, the IMS client uses the HTTP CONNECT method (see RFC 2817 [63]) to request the proxy to establish a TCP connection with the P-CSCF on its behalf. Once the client has received a positive reply from the proxy that the TCP connection has been established, the client initates the TLS handshake with the P-CSCF and establishes the TLS tunnel. Note that the use of the HTTP CONNECT method is completely transparent to P-CSCF.

Editor’s note: It needs to be verified that this does not interfere with the HTTP proxy settings on the UE.

W.3.1.3 Firewall traversal for IMS media plane using ICE and TURN

Firewall traversal for IMS media plane is accomplished by using the ICE protocol together with an enhanced version of TURN. ICE is defined in RFC 8445 [79] and RFC 8839 [80], and it is a protocol for performing NAT traversal of UDP based media streams. ICE in turn makes use of TURN, defined in RFC 5766 [60], which is a protocol for relaying media through a relay server. An IMS client that supports ICE will allocate relayed candidates at the TURN server and include the candidate information in the SDP offer/answer sent to the peer. The relayed candidates will be used as a last resort when the client and peer fail to establish a direct communication path. The communication between the client and the TURN server (this includes both the relayed media and the control information needed to setup the relayed candidates) can occur over UDP, TCP or TCP/TLS. By using TCP/TLS on port 443 (HTTPS) or TCP on port 80 (HTTP) the communication will appear as HTTP(S) to firewalls and will (typically) be allowed through. Using TCP instead of TLS/TCP reduces the overhead but will fail when the firewall performs DPI or if an HTTP proxy is present. An IMS client may be configured to use both TURN over TCP/80 and TURN over TLS/443, in such case, the client should prefer to use TURN over TCP/80 to avoid TLS overhead.

ICE and TURN have later on been extended to also support TCP based media. ICE TCP is defined in RFC 8445 [79] and RFC 8839 [80] and TURN TCP is defined in RFC 8656 [78]. One of the changes introduced in TURN TCP is that the multiple TCP connections are established between the client and TURN server: one for exchange of control information and one for each relayed TCP based media stream. All UDP based media streams are relayed over the same TCP connection that is used for the control information, just as in the original TURN protocol. The TURN server will use TCP/TLS on port 443 (HTTPS) or TCP over port 80 (HTTP) for all the connections. In order to reduce the TLS setup time when several TCP connections are established, the IMS client and TURN server may use the TLS session resumption feature.

An IMS client that is configured to use an HTTP proxy uses the HTTP CONNECT method (see RFC 2817 [63]) to request the proxy to establish a TCP connection with the TURN server. Once the client has received a positive reply from the proxy that the TCP connection has been established, the client initates the TLS handshake with the TURN server and establishes the TLS tunnel. This procedure is repeated once for every TCP connection the client establishes with the TURN server. Note that the use of the HTTP CONNECT method is completely transparent to TURN server.

Using ICE for firewall traversal is particularly suitable for IMS clients that already implement ICE for NAT traversal, since in this case only minimal changes are required to the client. Usage of ICE for IMS clients is specified in TS 23.228 [3] and TS 24.229 [8].

Note that there is no need to specify any keep-alive mechanism since this functionality is already included in ICE. The IMS client will send regular STUN keep-alives which ensures that the firewall pinholes are maintained.

Editor’s note: ICE TCP is required for TCP based media (e.g. MSRP) but is not yet supported in TS 23.228 [3] and TS 24.229 [8]. These specifications need to be updated.

Editor’s note: How the client is authenticated and authorized by the TURN server is ffs. One possibility is to use the SIP Digest credentials and the normal TURN authentication procedure. However, this would require an additional interface between the TURN server and the HSS. Another possibility is to use GBA but this would perhaps be unnecessarily complex considering that the only attack we need to protect against is DoS.

W.3.2 Reference model

Figure W.1 presents the reference model for IMS access when the IMS client uses the firewall traversal mechanism outlined in this section.

In case the remote endpoint does not support ICE, the P-CSCF may instruct the IMS-ALG to insert the IMS Access Gateway in the media path and terminate ICE. The procedure is described in TS 24.229 [8] and continues to function in the same way, i.e. the IMS-ALG and IMS-AGW are not impacted by the firewall traversal solution.

Note that the media may take several routes depending on which ICE candidates that succeed first. Media will only be relayed through the TURN server if all ICE candidates with higher priority fail.

Also note that the STUN server is included in Figure W.1 for sake of completeness. There is no impact on this function.

Figure W.1: Reference model for IMS access when firewall traversal is performed using SIP over TCP/TLS and ICE

W.3.3 Required functions of the UE

For firewall traversal of IMS control plane, the IMS client shall implement the following functionality:

– support SIP over TLS/TCP on the non-standard port 443 (HTTPS);

– support the SIP Digest authentication method according to Annex N;

– support the CRLF keep-alive technique defined in RFC 5626 [32] together with the negotiation mechanism defined in RFC 6223 [64];

– support the HTTP CONNECT method in RFC 2817 [63] for establishing the TLS tunnel with the P-CSCF when the IMS client is configured with an HTTP proxy.

For firewall traversal of IMS media plane, the IMS client shall implement the following functionality:

– support ICE for UDP and TCP based media streams according to Annex G of TS 23.228 [3];

– support TLS/TCP on non-standard port 443 and TCP on non-standard port 80 for communication with TURN server;

– support the HTTP CONNECT method in RFC 2817 [63] for establishing TLS tunnels with the TURN server when the IMS client is configured with an HTTP proxy.

Note that the HTTP CONNECT method is only used when the IMS client is configured with an HTTP proxy for outgoing HTTP(S) requests. The way in which the IMS client obtains the proxy address and port is out of scope.

W.3.4 Required functions of the P-CSCF

For firewall traversal of IMS control plane, the P-CSCF shall implement the following functionality:

– support SIP over TLS/TCP on the non-standard port 443 (HTTPS);

– support the SIP Digest authentication method according to Annex N;

– support the CRLF keep-alive technique defined in RFC 5626 [32] together with the negotiation mechanism defined in RFC 6223 [64].

W.3.5 Required functions of the TURN server

The TURN server shall, in addition to the requirements specified in Annex G of TS 23.228 [3], implement the following functionality:

– Support TLS/TCP on non-standard port 443 and (optionally) TCP on non-standard port 80 for communication with IMS client

W.3.6 Required functions of the IMS-ALG and IMS-AGW

The requirements for the IMS-ALG and IMS-AGW specified in TS 24.228 [11] apply without changes.

NOTE: The IMS-ALG is invoked by the P-CSCF, IBCF, or ISC to handle the case when the remote endpoint lacks support of ICE. The IMS-ALG in turn inserts the IMS-AGW on the media path.

Editor’s note: IMS-AGW may be inserted in other cases as well, e.g. for hosted NAT.

Annex X (Normative):
Security for WebRTC IMS Client access to IMS