F.2 UE – EPC network protocols
24.3023GPPAccess to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networksRelease 18Stage 3TS
F.2.1 General
In order to access to EPC via restrictive non-3GPP access network, the UE and the ePDG shall establish a firewall traversal tunnel (FTT) using the UE requested FTT establishment procedure according to clause F.2.2. Once the FTT is established, the UE shall initiate establishment of an IPSec tunnel via an IKEv2 protocol exchange according to IETF RFC 7296 [28].
The UE and the ePDG shall construct the IKEv2 messages according to clause 7 and according to clause F.2.3.
The UE and the ePDG shall send the IKEv2 messages using the IKEv2 message transport procedure according to clause F.2.2.3.
The UE and the ePDG shall send the encapsulating security payloads using the encapsulating security payload transport procedure according to clause F.2.2.4.
If the UE has not sent a message over the FTT in the last FTT KAT seconds, the UE shall perform the UE requested keep-alive procedure according to clause F.2.2.5.
When all IKEv2 security associations are closed, the UE shall perform the UE requested FTT release procedure according to clause F.2.2.6.
When all IKEv2 security associations are closed, the network can perform the network requested FTT release procedure according to clause F.2.2.7.
F.2.2 FTT protocol
F.2.2.1 General
The FTT protocol consists of the UE requested FTT establishment procedure, the IKEv2 message transport procedure, the encapsulating security payload transport procedure, the UE requested keep-alive procedure, the UE requested FTT release procedure and the network requested FTT release procedure.
F.2.2.2 UE requested FTT establishment procedure
F.2.2.2.1 General
The purpose of the UE requested FTT establishment procedure is to establish an FTT between the UE and the ePDG.
F.2.2.2.2 UE requested FTT establishment procedure initiation
If the UE is not configured with an HTTP proxy address, the UE shall follow the procedures in clause F.2.2.2.3.
If the UE is configured with an HTTP proxy address, the UE shall follow the procedures in clause F.2.2.2.4.
NOTE: UE configuration of an HTTP proxy address is out of scope of 3GPP.
F.2.2.2.3 UE requested FTT establishment procedure initiation via restrictive non-3GPP access network type I
In order to establish an FTT, the UE shall establish a TCP connection to the ePDG address and destination port 443.
If the TCP connection establishment is successful, the UE shall establish a TLS connection over the TCP connection according to the TLS profile specified in 3GPP TS 33.310 [65] annex E. If the ePDG address is a FQDN, the UE shall include a TLS extension of type "server_name" in the TLS client hello message according to the TLS profile specified in 3GPP TS 33.310 [65] annex E.
The ePDG shall handle the TCP connection setup and shall handle the TLS connection establishment according to the TLS profile specified in 3GPP TS 33.310 [65] annex E.
F.2.2.2.4 UE requested FTT establishment procedure initiation via restrictive non-3GPP access network type II
If the UE is configured with HTTP proxy address, in order to establish an FTT, the UE shall send HTTP CONNECT request to the HTTP proxy address according to IETF RFC 2817 [53]. The UE shall populate Request-URI of the HTTP CONNECT request with the ePDG address and port 443.
Upon receiving HTTP 2xx response to HTTP CONNECT request, the UE shall establish TLS connection according to the TLS profile specified in 3GPP TS 33.310 [65] annex E over the TCP connection used for the HTTP CONNECT request transport. If the ePDG address is a FQDN, the UE shall include a TLS extension of type "server_name" in the TLS client hello message according to the TLS profile specified in 3GPP TS 33.310 [65] annex E.
The ePDG shall handle the TCP connection setup and the TLS connection establishment according to the TLS profile specified in 3GPP TS 33.310 [65] annex E.
F.2.2.2.5 UE requested FTT establishment procedure accepted by the network
When TLS Finished message is sent over the TCP connection according to the TLS profile specified in 3GPP TS 33.310 [65] annex E, the ePDG shall use the connection as the FTT.
When valid TLS Finished message is received over the TCP connection, the UE shall use the connection as the FTT.
F.2.2.3 IKEv2 message transport procedure
F.2.2.3.1 General
The purpose of the IKEv2 message transport procedure is to transport an IKEv2 message over an FTT.
F.2.2.3.2 IKEv2 message transport procedure initiation
In order to send an IKEv2 message, the UE or the ePDG shall create an IKEv2 envelope as described in clause F.3.2.2, shall populate the Non-ESP marker field with zero value and shall populate the IKEv2 message field of the IKEv2 envelope with the IKEv2 message.
The UE shall send the IKEv2 envelope as TLS application data according to the TLS profile specified in 3GPP TS 33.310 [65] annex E:
– if the IKEv2 message is an IKEv2 request, over an FTT of the UE; and
– if the IKEv2 message is an IKEv2 response of an IKEv2 request, over the FTT over which the IKEv2 request was received.
The ePDG shall send the IKEv2 envelope as TLS application data according to the TLS profile specified in 3GPP TS 33.310 [65] annex E:
– if the IKEv2 message is an IKEv2 request of an IKEv2 security association, over the FTT associated with the IKEv2 security association; and
– if the IKEv2 message is an IKEv2 response of an IKEv2 request, over the FTT over which the IKEv2 request was received.
F.2.2.3.3 IKEv2 message transport procedure accepted
Upon receiving the IKEv2 envelope as TLS application data over the FTT, the ePDG or the UE shall extract the IKEv2 message from the IKEv2 envelope as described in clause F.3.2.2 and shall handle it according to IETF RFC 7296 [28]. If the IKEv2 message is a validated IKEv2 packet, the ePDG shall associate the FTT with the IKEv2 security association of the validated packet (replacing any FTT previously associated with the IKEv2 security association).
F.2.2.4 Encapsulating security payload transport procedure
F.2.2.4.1 General
The purpose of the encapsulating security payload transport procedure is to transport an encapsulating security payload over an FTT.
F.2.2.4.2 Encapsulating security payload transport initiation
In order to send an encapsulating security payload, the UE or the ePDG shall create a ESP envelope as described in clause F.3.2.3 and shall populate the ESP message field of the ESP envelope with the encapsulating security payload.
The UE shall send the ESP envelope as TLS application data according to the TLS profile specified in 3GPP TS 33.310 [65] annex E over an FTT of the UE.
The ePDG shall send the ESP envelope as TLS application data according to the TLS profile specified in 3GPP TS 33.310 [65] annex E over the FTT associated with the IKEv2 security association which established the child security association of the encapsulating security payload.
F.2.2.4.3 Encapsulating security payload transport accepted
Upon receiving the ESP envelope over the FTT, the ePDG or the UE shall extract the encapsulating security payload from the ESP envelope as described in clause F.3.2.3 and shall handle it according to IETF RFC 4303 [32].
F.2.2.5 UE requested keep-alive procedure
F.2.2.5.1 General
The purpose of the UE requested keep-alive procedure is to refresh binding in firewall (possibly including NAT) deployed between the restrictive non-3GPP access network and the EPC.
F.2.2.5.2 UE requested keep-alive procedure initiation
In order to send a keep-alive, the UE shall create a keep-alive envelope as described in clause F.3.2.4.
The UE shall send the keep-alive envelope as TLS application data according to the TLS profile specified in 3GPP TS 33.310 [65] annex E over an FTT of the UE.
F.2.2.5.3 UE requested keep-alive procedure accepted by the network
The ePDG shall discard any keep-alive envelope received over the FTT.
F.2.2.6 UE requested FTT release procedure
F.2.2.6.1 General
The purpose of the UE requested FTT release procedure is to release an FTT when all IKEv2 security associations are closed.
F.2.2.6.2 UE requested FTT release procedure initiation
In order to release the FTT, the UE shall send TLS close_notify alert according to the TLS profile specified in 3GPP TS 33.310 [65] annex E.
F.2.2.6.3 UE requested FTT release procedure accepted by the network
The ePDG shall handle the TLS close_notify alert according to the TLS profile specified in 3GPP TS 33.310 [65] annex E.
F.2.2.7 Network requested FTT release procedure
F.2.2.7.1 General
The purpose of the network requested FTT release procedure is to release an FTT when all IKEv2 security associations are closed.
F.2.2.7.2 Network requested FTT release procedure initiation
In order to release the FTT, the ePDG shall send TLS close_notify alert according to the TLS profile specified in 3GPP TS 33.310 [r33310] annex E.
F.2.2.7.3 Network requested FTT release procedure accepted by the UE
The UE shall handle the TLS close_notify alert according to the TLS profile specified in 3GPP TS 33.310 [65] annex E.
F.2.3 Additional IKEv2 procedures when FTT is used
F.2.3.1 FTT KAT negotiation during tunnel establishment
The UE shall include the FTT_KAT configuration attribute according to clause F.3.3.1 in the IKEv2 CFG_REQUEST configuration payload of the IKE_AUTH request message sent via FTT.
If the FTT_KAT configuration attribute is included in the IKEv2 CFG_REQUEST configuration payload, ePDG shall include the FTT_KAT configuration attribute according to clause F.3.3.1 in the IKEv2 CFG_REPLY configuration payload.
If the FTT_KAT configuration attribute is not included in the IKEv2 CFG_REPLY configuration payload, the UE shall determine the firewall traversal tunnel keep-alive time (FTT KAT) as a random number uniformly distributed between lower bound and higher bound. The default value for lower bound is 672 seconds and the default value for higher bound is 840 seconds.
If the FTT_KAT configuration attribute is included in the IKEv2 CFG_REPLY configuration payload, the UE shall set the FTT KAT to the value of the Keep-alive time field of the FTT_KAT configuration attribute.