7 Security association management procedures
24.5023GPPAccess to the 3GPP 5G Core Network (5GCN) via non-3GPP access networksRelease 18TS
7.1 General
The purpose of the security association management procedures is to define the procedures for establishment or disconnection of end-to-end security association between the UE and the N3IWF via an IKEv2 protocol exchange specified in IETF RFC 7296 [6]. The IKE SA and child signalling IPsec SA establishment procedure is always initiated by the UE, whereas the child user plane IPsec SA creation procedures shall be initiated by the N3IWF as specified in 3GPP TS 23.502 [3].
The UE selects an N3IWF according to the procedure in clause 7.2. Once the N3IWF has been selected, the security associations are established managed according to the procedures in clause 7.3 to clause 7.7.
If a non-3GPP access network does not support transport of IP fragments, the maximum size of an IKEv2 message including the IP header is equal to the path MTU between the UE and N3IWF.
EXAMPLE: If a non-3GPP access network is an IPv6 only network which does not support transport of IP fragments and the path MTU between the UE and the N3IWF is 1280 octets then the maximum size of an IKEv2 message including IP header is 1280 octets.
7.2 N3AN node selection procedure
7.2.1 General
The UE performs N3AN node selection procedure based on the N3AN node configuration information provisioned to the UE by the HPLMN, based on the UE’s knowledge of the country the UE is located in and the PLMN the UE is registered to via 3GPP access and based on the list of "forbidden PLMNs for non-3GPP access to 5GCN".
Clauses 7.2.1, 7.2.2, 7.2.3, 7.2.4 and 7.2.6 are applicable to a UE selecting an N3AN node in a PLMN. For a UE accessing PLMN services via an SNPN, restrictions on N3IWF FQDN are specified in clause 4.3.2.
Clause 7.2.5 is applicable to a UE selecting an N3AN node in an SNPN.
7.2.2 N3AN node configuration information
The N3AN node configuration information is provisioned to the UE either by H-PCF or via implementation specific means. The UE shall apply the N3AN node configuration information provisioned via implementation specific means only if the N3AN node configuration information provisioned by the H-PCF is not present in the UE.
The N3AN node configuration information shall consist of the following:
– N3AN node selection information;
– optionally, home N3IWF identifier configuration; and
– optionally, home ePDG identifier configuration.
The N3AN node selection information consists of N3AN node selection information entries. Each N3AN node selection information entry contains a PLMN ID and information for the PLMN ID. The N3AN node selection information contains at least an N3AN node selection information entry with information for the HPLMN and an N3AN node selection information entry for "any_PLMN".
The N3AN node configuration information provisioned by H-PCF is as specified in 3GPP TS 24.501 [4] annex D and 3GPP TS 24.526 [17].
The UE shall support the implementation of standard DNS mechanisms in order to retrieve the IP address(es) of the N3IWF or ePDG. The input to the DNS query is an N3IWF FQDN or ePDG FQDN as specified in 3GPP TS 23.003 [8].
7.2.3 Determination of the country the UE is located in
If the UE cannot determine whether it is located in the home country or in a visited country, as required by the N3AN node selection procedure, the UE shall stop the N3AN node selection. Once the UE determines the country the UE is located in, the UE shall proceed with N3AN node selection as specified in clause 7.2.4 for non-emergency services and as specified in clause 7.2.6 for emergency services.
NOTE: It is out of scope of the present specification to define how the UE determines whether it is located in the home country or in a visited country or in a location that does not belong to any country. When the UE is in coverage of a 3GPP RAT, it can, for example, use the information derived from the available PLMN(s). In this case, the UE can match the MCC of the PLMN to which a cell belongs, broadcast on the BCCH of the 3GPP access, against the UE’s IMSI to determine if they belong to the same country, as defined in 3GPP TS 23.122 [13]. If the UE is not in coverage of a 3GPP RAT, the UE can use other techniques, including user-provided location.
7.2.4 N3AN node selection for non-emergency services
7.2.4.1 General
When the UE supports connectivity with N3IWF but does not support connectivity with ePDG, the UE shall perform the procedure in clause 7.2.4.3 for selecting an N3IWF.
When the UE supports connectivity with N3IWF and ePDG, the UE shall perform the procedure in clause 7.2.4.4 for selecting either an N3IWF or an ePDG.
7.2.4.2 Determine if the visited country mandates the selection of N3IWF in this country
In order to determine if the visited country mandates the selection of N3IWF in this country, the UE shall perform the DNS NAPTR query using Visited Country FQDN as specified in 3GPP TS 23.003 [8] via the non-3GPP access network.
If the result of this query is:
– a set of one or more records containing the service instance names of the form "n3iwf.5gc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org", the UE shall determine that the visited country mandates the selection of the N3IWF in this country; and
NOTE: The (<MCC>, <MNC>) pair in each record represents PLMN Id (see 3GPP TS 23.003 [8]) in the visited country which can be used for N3IWF selection in clause 7.2.4.3 and clause 7.2.4.4.
– no records containing the service instance names of the form "n3iwf.5gc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org", the UE shall determine that the visited country does not mandate the selection of the N3IWF in this country.
7.2.4.3 UE procedure when the UE only supports connectivity with N3IWF
If the UE only supports connectivity with N3IWF and does not support connectivity with ePDG, the UE shall ignore the following ePDG related configuration parameters if available in the N3AN node configuration information when selecting an N3IWF:
– the home ePDG identifier configuration; and
– the preference parameter in each N3AN node selection information entry in the N3AN node selection information.
The UE shall proceed as follows:
a) if the UE is located in its home country:
1) if the N3AN node configuration information is provisioned:
i) if the home N3IWF identifier configuration is provisioned in the N3AN node configuration information and contains an IP address, the UE shall use the IP address of the home N3IWF identifier configuration as the IP address of the N3IWF;
ii) if the home N3IWF identifier configuration is provisioned in the N3AN node configuration information and does not contain an IP address, the UE shall use the FQDN of the home N3IWF identifier configuration as the N3IWF FQDN; and
iii) if the home N3IWF identifier configuration is not provisioned in the N3AN node configuration information, the UE shall construct an N3IWF FQDN based on the FQDN format of the HPLMN’s N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the HPLMN stored on the USIM as specified in 3GPP TS 23.003 [8]; and
2) if the N3AN node configuration information is not provisioned on the UE, the UE shall construct the N3IWF FQDN based on the Operator Identifier FQDN format using the PLMN ID of the HPLMN stored on the USIM;
and for the above cases constructing or using an N3IWF FQDN, the UE shall use the DNS server function to resolve the N3IWF FQDN to the IP address(es) of the N3IWF(s). The UE shall select as the IP address of the N3IWF a resolved IP address of an N3IWF with the same IP version as its local IP address; and
b) if the UE is not located in its home country:
1) if the N3AN node configuration information is provisioned, the UE is registered to a VPLMN via 3GPP access, the PLMN ID of VPLMN is not included in the list of "forbidden PLMNs for non-3GPP access to 5GCN", and an N3AN node selection information entry for the VPLMN is available in the N3AN node selection information of the N3AN node configuration information, the UE shall construct an N3IWF FQDN based on FQDN format of the VPLMN’s N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the VPLMN as specified in 3GPP TS 23.003 [8];
and for the above case, the UE shall use the DNS server function to resolve the constructed N3IWF FQDN to the IP address(es) of the N3IWF(s). The UE shall select as the IP address of the N3IWF a resolved IP address of an N3IWF with the same IP version as its local IP address; and
2) if one of the following is true:
– the UE is not registered to a PLMN via 3GPP access and the UE uses WLAN;
– the N3AN node configuration information is not provisioned; or
– the N3AN node configuration information is provisioned, the UE is registered to a VPLMN via 3GPP access and:
A) the PLMN ID of VPLMN is included in the list of "forbidden PLMNs for non-3GPP access to 5GCN"; or
B) the N3AN node selection information entry for the VPLMN is not present in the N3AN node selection information;
the UE shall perform a DNS query (see 3GPP TS 23.003 [8]) as specified in clause 7.2.4.2 to determine if the visited country mandates the selection of N3IWF in this country and:
i) if selection of N3IWF in visited country is mandatory:
A) if the UE is registered to a VPLMN via 3GPP access, the PLMN ID of VPLMN is included in one of the returned DNS records and is not included in the list of "forbidden PLMNs for non-3GPP access to 5GCN", the UE shall construct an N3IWF FQDN based on the Operator Identifier FQDN format using the PLMN ID of the VPLMN in 3GPP access as described in 3GPP TS 23.003 [8]; and
B) if the UE is not registered to a PLMN via 3GPP access or the UE is registered to a VPLMN via 3GPP access and the PLMN ID of VPLMN is not included in any of the returned DNS records or is included in the list of "forbidden PLMNs for non-3GPP access to 5GCN":
– if the N3AN node configuration information is provisioned, the UE shall select a PLMN included in the DNS response that has highest PLMN priority (see 3GPP TS 24.526 [17]) in the N3AN node selection information of the N3AN node configuration information excluding any PLMN in the list of "forbidden PLMNs for non-3GPP access to 5GCN" and the UE shall construct an N3IWF FQDN based on the FQDN format of the selected PLMN’s N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the selected PLMN as specified in 3GPP TS 23.003 [8]; and
– if the N3AN node configuration information is not provisioned or the N3AN node selection information of the N3AN node configuration information excluding any PLMN in the list of "forbidden PLMNs for non-3GPP access to 5GCN" does not contain any of the PLMNs in the DNS response, selection of a PLMN of the visited country is UE implementation specific. If the UE does not select a PLMN, the UE shall terminate the N3AN node selection procedure. If the UE selects a PLMN, the UE shall construct an N3IWF FQDN based on the Operator Identifier FQDN format using the PLMN ID of the selected PLMN as described in 3GPP TS 23.003 [8];
and for the above cases, the UE shall use the DNS server function to resolve the constructed N3IWF FQDN to the IP address(es) of the N3IWF(s). The UE shall select as the IP address of the N3IWF a resolved IP address of an N3IWF with the same IP version as its local IP address;
ii) if the DNS response contains no records, the UE shall further determine if the visited country mandates the selection of ePDG in the visited country using the procedure specified in clause 7.2.1.4 of 3GPP TS 24.302 [7].
If the UE determines that the visited country mandates the selection of ePDG in the visited country, the UE shall assume that the selection of N3IWF in the visited country is mandatory and shall terminate the N3AN node selection procedure.
– If the UE determines that the visited country does not mandate the selection of ePDG in the visited country, the UE shall assume that the selection of N3IWF in the visited country is not mandatory, then the UE shall proceed as below:
A) if the N3AN node configuration information is provisioned and the N3AN node selection information of the N3AN node configuration information contains one or more PLMNs in the visited country which are not in the list of "forbidden PLMNs for non-3GPP access to 5GCN", the UE shall select a PLMN that has highest PLMN priority (see 3GPP TS 24.526 [17]) in the N3AN node selection information excluding any PLMN in the list of "forbidden PLMNs for non-3GPP access to 5GCN" and the UE shall construct an N3IWF FQDN based on the FQDN format of the selected PLMN’s N3AN node selection information entry in the N3AN node selection information as specified in 3GPP TS 23.003 [8] using the PLMN ID of the selected PLMN; and
B) if the N3AN node configuration information is not provisioned or the N3AN node configuration information is provisioned and the N3AN node selection information of the N3AN node configuration information excluding any PLMN in the list of "forbidden PLMNs for non-3GPP access to 5GCN" contains no PLMNs in the visited country:
– if the home N3IWF identifier configuration is provisioned in the N3AN node configuration information (see 3GPP TS 24.526 [17]) and contains an IP address, the UE shall use the IP address of the home N3IWF identifier configuration as the IP address of the N3IWF;
– if the home N3IWF identifier configuration is provisioned in the N3AN node configuration information (see 3GPP TS 24.526 [17]) and does not contain an IP address, the UE shall use the FQDN of the home N3IWF identifier configuration as the N3IWF FQDN; and
– if the home N3IWF identifier configuration is not provisioned in the N3AN node configuration information, the UE shall construct an N3IWF FQDN based on the Operator Identifier FQDN format using the PLMN ID of the HPLMN as described in 3GPP TS 23.003 [8];
and for the above cases constructing or using an N3IWF FQDN, the UE shall use the DNS server function to resolve the N3IWF FQDN to the IP address(es) of the N3IWF(s). The UE shall select as the IP address of the N3IWF a resolved IP address of an N3IWF with the same IP version as its local IP address; and
iii) if no DNS response is received, the UE shall terminate the N3AN node selection procedure.
Following bullet a) and b) above, once the UE selected the IP address of the N3IWF, the UE shall initiate the IKEv2 SA establishment procedure as specified in clause 7.3.
If the IKEv2 SA establishment procedure towards an N3IWF in the HPLMN fails due to no response to an IKE_SA_INIT request message, and the selection of N3IWF in the HPLMN is performed using home N3IWF identifier configuration and there are more pre-configured N3IWFs in the HPLMN, the UE shall repeat the tunnel establishment attempt using the next FQDN or IP address(es) of the N3IWF in the HPLMN.
If the IKEv2 SA establishment procedure towards to any of the received IP addresses of the selected N3IWF fails due to no response to an IKE_SA_INIT request message, then the UE shall repeat the N3IWF selection as described in this clause, excluding the N3IWFs for which the UE did not receive a response to the IKE_SA_INIT request message.
If the UE constructed an N3IWF FQDN based on FQDN format of the VPLMN’s N3AN node selection information entry (see item b).1)), and the IKEv2 SA establishment procedure towards to each of the received IP addresses of the selected N3IWF failed due to no response to an IKE_SA_INIT request message, the UE considers the N3AN node selection information entry for the VPLMN as not present in the N3AN node selection information and the UE shall repeat the N3IWF selection as described in this clause.
NOTE: The time the UE waits before reattempting access to another N3IWF or to an N3IWF that it previously did not receive a response to an IKE_SA_INIT request message, is implementation specific.
7.2.4.4 UE procedure when the UE supports connectivity with N3IWF and ePDG
7.2.4.4.1 General
If the UE can support connectivity with N3IWF and with ePDG, the UE shall:
– if the N3AN node selection is required for an IMS service, follow steps specified in clause 7.2.4.4.2 for N3AN node selection; and
– if the N3AN node selection is required for a non-IMS service, follow steps specified in clause 7.2.4.4.3 for N3AN node selection.
NOTE: How the UE determines node selection is required for an IMS service or for a non-IMS service is implementation-specific.
7.2.4.4.2 N3AN node selection for IMS service
If the N3AN node selection is required for an IMS service, the UE shall use the preference parameter in the N3AN node selection information entries of the N3AN node selection information to determine whether selection of N3IWF or ePDG is preferred in a given PLMN.
The UE shall proceed as follows:
a) if the UE is located in its home country:
1) if the N3AN node configuration information is provisioned:
i) if the preference parameter in the HPLMN’s N3AN node selection information entry of the N3AN node selection information indicates that N3IWF is preferred:
A) if the home N3IWF identifier configuration is provisioned in the N3AN node configuration information and contains an IP address, the UE shall use the IP address of the home N3IWF identifier configuration as the IP address of the N3IWF;
B) if the home N3IWF identifier configuration is provisioned in the N3AN node configuration information and does not contain an IP address, the UE shall use the FQDN of the home N3IWF identifier configuration as the N3IWF FQDN; and
C) if the home N3IWF identifier configuration is not provisioned in the N3AN node configuration information, the UE shall construct an N3IWF FQDN based on the FQDN format of the HPLMN’s N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the HPLMN stored on the USIM as specified in clause 28 of 3GPP TS 23.003 [8]; and
ii) if the preference parameter in the HPLMN’s N3AN node selection information entry of the N3AN node selection information indicates that ePDG is preferred:
A) if the home ePDG identifier configuration is provisioned in the N3AN node configuration information and contains an IP address, the UE shall use the IP address of the home ePDG identifier configuration as the IP address of the ePDG;
B) if the home ePDG identifier configuration is provisioned in the N3AN node configuration information and does not contains an IP address, the UE shall use the FQDN of the home ePDG identifier configuration as the ePDG FQDN; and
C) if the home ePDG identifier configuration is not provisioned in the N3AN node configuration information, the UE shall construct an ePDG FQDN based on the FQDN format of HPLMN’s N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the HPLMN stored on the USIM as specified in clause 19 of 3GPP TS 23.003 [8]; and
2) if the N3AN node configuration information is not provisioned on the UE, the UE shall construct the N3IWF FQDN based on the Operator Identifier FQDN format using the PLMN ID of the HPLMN stored on the USIM;
and for the above cases constructing or using an N3IWF FQDN or ePDG FQDN, the UE shall use the DNS server function to resolve the N3IWF FQDN or ePDG FQDN to the IP address(es) of the N3IWF(s) or ePDG(s). The UE shall select as the IP address of the N3IWF or of the ePDG a resolved IP address of an N3IWF or an ePDG with the same IP version as its local IP address; and
b) if the UE is not located in its home country:
1) if the N3AN node configuration information is provisioned, the UE is registered to a VPLMN via 3GPP access and the PLMN ID of VPLMN is not included in the list of "forbidden PLMNs for non-3GPP access to 5GCN":
i) if an N3AN node selection information entry for the VPLMN is available in the N3AN node selection information of the N3AN node configuration information:
A) if the preference parameter in the VPLMN’s N3AN node selection information entry of the N3AN node configuration information indicates that N3IWF is preferred, the UE shall construct an N3IWF FQDN based on the FQDN format of the VPLMN’s N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the VPLMN as specified in clause 28 of 3GPP TS 23.003 [8]; and
B) if the preference parameter in the VPLMN’s N3AN node selection information entry of the N3AN node configuration information indicates that ePDG is preferred, the UE shall construct an ePDG FQDN based on the FQDN format of the VPLMN’s N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the VPLMN as specified in clause 19 of 3GPP TS 23.003 [8];
and for above case, the UE shall use the DNS server function to resolve the constructed N3IWF FQDN or ePDG FQDN to the IP address(es) of the N3IWF(s) or ePDG(s). The UE shall select as the IP address of the N3IWF or the ePDG a resolved IP address of an N3IWF or ePDG with the same IP version as its local IP address; and
2) if one of the following is true:
– the UE is not registered to a PLMN via 3GPP access and the UE uses WLAN;
– the N3AN node configuration information is not provisioned; or
– the N3AN node configuration information is provisioned, the UE is registered to a VPLMN via 3GPP access and:
A) the PLMN ID of VPLMN is included in the list of "forbidden PLMNs for non-3GPP access to 5GCN"; or
B) the N3AN node selection information entry for the VPLMN is not present in the N3AN node selection information;
the UE shall perform a DNS query (see 3GPP TS 23.003 [8]) as specified in clause 7.2.4.2 to determine if the visited country mandates the selection of N3IWF in this country and:
i) if selection of N3IWF in the visited country is mandatory:
A) if the UE is registered to a VPLMN via 3GPP access, the PLMN ID of VPLMN is included in one of the returned DNS records and is not included in the list of "forbidden PLMNs for non-3GPP access to 5GCN", the UE shall construct an N3IWF FQDN based on the Operator Identifier FQDN format using the PLMN ID of the VPLMN as described in clause 28 of 3GPP TS 23.003 [8]; and
B) if the UE is not registered to a PLMN via 3GPP access, or the UE is registered to a VPLMN via 3GPP access and the PLMN ID of VPLMN is not included in any of the returned DNS records or is included in the list of "forbidden PLMNs for non-3GPP access to 5GCN":
– if the N3AN node configuration information is provisioned, the UE shall select an a PLMN included in the DNS response that has highest PLMN priority (see 3GPP TS 24.526 [17]) in the N3AN node selection information of the N3AN node configuration information excluding any PLMN in the list of "forbidden PLMNs for non-3GPP access to 5GCN" and the UE shall construct an N3IWF FQDN based on the FQDN format of the selected PLMN’s N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the selected PLMN as specified clause 28 of in 3GPP TS 23.003 [8]; and
– if the N3AN node configuration information is not provisioned or the N3AN node selection information of the N3AN node configuration information excluding any PLMN in the list of "forbidden PLMNs for non-3GPP access to 5GCN" does not contain any of the PLMNs in the DNS response, selection of the PLMN is UE implementation specific. The UE shall construct an N3IWF FQDN based on the Operator Identifier FQDN format using the PLMN ID of the selected PLMN as described clause 28 of in 3GPP TS 23.003 [8];
and for the above cases, the UE shall use the DNS server function to resolve the constructed N3IWF FQDN to the IP address(es) of the N3IWF(s). The UE shall select as the IP address of the N3IWF a resolved IP address of an N3IWF with the same IP version as its local IP address;
ii) if the DNS response contains no records, the UE shall further determine if the visited country mandates the selection of ePDG in the visited country using the procedure specified in clause 7.2.1.4 of 3GPP TS 24.302 [7].
If the UE determines that the visited country mandates the selection of ePDG in the visited country, the UE shall assume that the selection of N3IWF in the visited country is mandatory and shall continue the ePDG selection procedure in the visited country, specified in clause 7.2.1.3 of 3GPP TS 24.302 [7].
If the UE determines that the visited country does not mandate the selection of ePDG in the visited country, the UE shall assume that the selection of N3IWF in the visited country is not mandatory and the UE shall proceed as below:
A) if the N3AN node configuration information is provisioned and the N3AN node selection information of the N3AN node configuration information contains one or more PLMNs in the visited country which are not included in the list of "forbidden PLMNs for non-3GPP access to 5GCN", the UE shall select a PLMN that has highest PLMN priority (see 3GPP TS 24.526 [17]) in the N3AN node selection information excluding any PLMN in the list of "forbidden PLMNs for non-3GPP access to 5GCN" and the UE shall construct an N3IWF FQDN based on the FQDN format of the selected PLMN’s N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the selected PLMN as specified in clause 28 of 3GPP TS 23.003 [8]; and
B) if the N3AN node configuration information is not provisioned or the N3AN node configuration information is provisioned and the N3AN node selection information of the N3AN node configuration information excluding any PLMN in the list of "forbidden PLMNs for non-3GPP access to 5GCN" contains no PLMN in the visited country:
– if the home N3IWF identifier configuration is provisioned in the N3AN node configuration information (see 3GPP TS 24.526 [17]) and contains an IP address, the UE shall use the IP address of the home N3IWF identifier configuration as the IP address of the N3IWF;
– if the home N3IWF identifier configuration is provisioned in the N3AN node configuration information (see 3GPP TS 24.526 [17]) and does not contains an IP address, the UE shall use the FQDN of the home N3IWF identifier configuration as N3IWF FQDN; and
– if the home N3IWF identifier configuration is not provisioned in the N3AN node configuration information, the UE shall construct an N3IWF FQDN based on the Operator Identifier FQDN format using the PLMN ID of the HPLMN as described in clause 28 of 3GPP TS 23.003 [8];
and for the above cases constructing or using an N3IWF FQDN, the UE shall use the DNS server function to resolve the N3IWF FQDN to the IP address(es) of the N3IWF(s). The UE shall select as the IP address of the N3IWF a resolved IP address of an N3IWF with the same IP version as its local IP address; and
iii) if no DNS response is received, the UE shall terminate the N3AN node selection procedure.
Following bullet a) and b) above, once the UE selected the IP address of the N3IWF or the ePDG:
a) if the IP address of N3IWF is selected, the UE shall:
i) initiate the IKEv2 SA establishment procedure as specified in clause 7.3;
ii) if the IKEv2 SA establishment procedure towards an N3IWF in the HPLMN fails due to no response to an IKE_SA_INIT request message or the UE is informed during registration over non-3GPP access that the IMS voice over PS session is not supported over non-3GPP access, and the selection of N3IWF in the HPLMN is performed using home N3IWF identifier configuration and there are more pre-configured N3IWFs in the HPLMN, repeat the tunnel establishment attempt using the next FQDN or IP address(es) of the N3IWF in the HPLMN;
iii) if the IKEv2 SA establishment procedure towards any of the received IP addresses of the selected N3IWF fails due to no response to an IKE_SA_INIT request message or the UE is informed during registration over non-3GPP access that the IMS voice over PS session is not supported over non-3GPP access, attempt to select an ePDG in the same PLMN as specified in 3GPP TS 24.302 [7] instead;
iv) if the UE fails to connect to either N3IWF or ePDG in the same PLMN, repeat the N3AN node selection as described in this clause, excluding the N3IWFs for which the UE did not receive a response to the IKE_SA_INIT request message; and
v) if the UE fails to connect to either N3IWF or ePDG in the VPLMN with which it is registered via 3GPP access, the UE considers the N3AN node selection information entry for the VPLMN as not present in the N3AN node selection information and the UE shall repeat the N3IWF selection as described in this clause;
NOTE 1: The time the UE waits before reattempting access to another N3IWF or to an N3IWF that it previously did not receive a response to an IKE_SA_INIT request message, is implementation specific.
b) if the IP address of ePDG is selected, the UE shall:
i) initiate tunnel establishment as specified in 3GPP TS 24.302 [7];
ii) if tunnel establishment as specified in 3GPP TS 24.302 [7] towards an ePDG in the HPLMN fails due to no response to an IKE_SA_INIT request message, and the selection of ePDG in the HPLMN is performed using home ePDG identifier configuration and there are more pre-configured ePDG in the HPLMN, repeat the tunnel establishment attempt using the next FQDN or IP address(es) of the ePDG in the HPLMN;
iii) if tunnel establishment as specified in 3GPP TS 24.302 [7] towards any of the received IP addresses of the selected ePDG fails due to no response to an IKE_SA_INIT request message, attempt to select an N3IWF in the same PLMN instead;
iv) if the UE fails to connect to either ePDG or N3IWF in the same PLMN, repeat the N3AN node selection as described in this clause, excluding the ePDGs for which the UE did not receive a response to the IKE_SA_INIT request message; and
v) if the UE fails to connect to either ePDG or N3IWF in the VPLMN with which it is registered via 3GPP access, the UE considers the N3AN node selection information entry for the VPLMN as not present in the N3AN node selection information and the UE shall repeat the N3IWF selection as described in this clause.
NOTE 2: The time the UE waits before reattempting access to another ePDG or to an ePDG that it previously did not receive a response to an IKE_SA_INIT request message, is implementation specific.
7.2.4.4.3 N3AN node selection for Non-IMS service
If the N3AN node selection is required for a non-IMS service, the UE shall ignore the preference parameter in the N3AN node selection information entries of the N3AN node selection information.
The UE shall proceed as follows:
a) if the UE is located in its home country:
1) if the N3AN node configuration information is provisioned:
i) if the home N3IWF identifier configuration is provisioned in the N3AN node configuration information and contains an IP address, the UE shall use the IP address of the home N3IWF identifier configuration as the IP address of the N3IWF;
ii) if the home N3IWF identifier configuration is provisioned in the N3AN node configuration information and does not contain an IP address, the UE shall use the FQDN of the home N3IWF identifier configuration as the N3IWF FQDN; and
iii) if the home N3IWF identifier configuration is not provisioned in the N3AN node configuration information, the UE shall construct an N3IWF FQDN based on the FQDN format of the HPLMN’s N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the HPLMN stored on the USIM as specified in clause 28 of 3GPP TS 23.003 [8]; and
2) if the N3AN node configuration information is not provisioned, the UE shall construct the N3IWF FQDN based on the Operator Identifier FQDN format using the PLMN ID of the HPLMN stored on the USIM;
and for the above cases constructing or using an N3IWF FQDN, the UE shall use the DNS server function to resolve the N3IWF FQDN to the IP address(es) of the N3IWF(s) or ePDG(s). The UE shall select as the IP address of the N3IWF a resolved IP address of an N3IWF with the same IP version as its local IP address; and
b) if the UE is not located in its home country:
1) if the N3AN node configuration information is provisioned, the UE is registered to a VPLMN via 3GPP access, the PLMN ID of VPLMN is not included in the list of "forbidden PLMNs for non-3GPP access to 5GCN", and an N3AN node selection information entry for the VPLMN is available in the N3AN node selection information of the N3AN node configuration information, the UE shall construct an N3IWF FQDN based on the FQDN format of the VPLMN’s N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the VPLMN as specified in clause 28 of 3GPP TS 23.003 [8];
and for above case, the UE shall use the DNS server function to resolve the constructed N3IWF FQDN to the IP address(es) of the N3IWF(s). The UE shall select as the IP address of the N3IWF a resolved IP address of an N3IWF with the same IP version as its local IP address; and
2) if one of the following is true:
– the UE is not registered to a PLMN via 3GPP access and the UE uses WLAN;
– the N3AN node configuration information is not provisioned; or
– the N3AN node configuration information is provisioned, the UE is registered to a VPLMN via 3GPP access and:
A) the PLMN ID of VPLMN is included in the list of "forbidden PLMNs for non-3GPP access to 5GCN"; or
B) the N3AN node selection information entry for the VPLMN is not present in the N3AN node selection information;
the UE shall perform a DNS query (see 3GPP TS 23.003 [8]) as specified in clause 7.2.4.2 to determine if the visited country mandates the selection of N3IWF in this country and:
i) if selection of N3IWF in the visited country is mandatory:
A) if the UE is registered to a VPLMN via 3GPP access, the PLMN ID of VPLMN is included in one of the returned DNS records and is not included in the list of "forbidden PLMNs for non-3GPP access to 5GCN", the UE shall construct an N3IWF FQDN based on the Operator Identifier FQDN format using the PLMN ID of the VPLMN as described in clause 28 of 3GPP TS 23.003 [8]; and
B) if the UE is not registered to a PLMN via 3GPP access or the UE is registered to a VPLMN via 3GPP access and the PLMN ID of VPLMN is not included in any of the returned DNS records or is included in the list of "forbidden PLMNs for non-3GPP access to 5GCN":
– if the N3AN node configuration information is provisioned, the UE shall select an a PLMN included in the DNS response that has highest PLMN priority (see 3GPP TS 24.526 [17]) in the N3AN node selection information of the N3AN node configuration information excluding any PLMN in the list of "forbidden PLMNs for non-3GPP access to 5GCN" and the UE shall construct an N3IWF FQDN based on the FQDN format of the selected PLMN’s N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the selected PLMN as specified in clause 28 of 3GPP TS 23.003 [8]; and
– if the N3AN node configuration information is not provisioned or the N3AN node selection information of the N3AN node configuration information excluding any PLMN in the list of "forbidden PLMNs for non-3GPP access to 5GCN" does not contain any of the PLMNs in the DNS response, selection of the PLMN is UE implementation specific. The UE shall construct an N3IWF FQDN based on the Operator Identifier FQDN format using the PLMN ID of the selected PLMN as described in clause 28 of 3GPP TS 23.003 [8];
and for the above cases, the UE shall use the DNS server function to resolve the constructed N3IWF FQDN to the IP address(es) of the N3IWF(s). The UE shall select as the IP address of the N3IWF a resolved IP address of an N3IWF with the same IP version as its local IP address;
ii) if the DNS response contains no records, the UE shall further determine if the visited country mandates the selection of ePDG in the visited country using the procedure specified in clause 7.2.1.4 of 3GPP TS 24.302 [7].
determines that the visited country mandates the selection of ePDG in the visited country, the UE shall assume that the selection of N3IWF in the visited country is mandatory and shall continue the ePDG selection procedure in the visited country, specified in clause 7.2.1.3 of 3GPP TS 24.302 [7].
If the UE determines that the visited country does not mandate the selection of ePDG in the visited country, the UE shall assume that the selection of N3IWF in the visited country is not mandatory and the UE shall proceed as follows:
A) if the N3AN node configuration information is provisioned and the N3AN node selection information of the N3AN node configuration information contains one or more PLMNs in the visited country which are not in the list of "forbidden PLMNs for non-3GPP access to 5GCN", the UE shall select a PLMN that has highest PLMN priority (see 3GPP TS 24.526 [17]) in the N3AN node selection information excluding any PLMN in the list of "forbidden PLMNs for non-3GPP access to 5GCN" and the UE shall construct an N3IWF FQDN based on the FQDN format of the selected PLMN’s N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the selected PLMN as specified in clause 28 of 3GPP TS 23.003 [8]; and
B) if the N3AN node configuration information is not provisioned or the N3AN node configuration information is provisioned and the N3AN node selection information of the N3AN node configuration information excluding any PLMN in the list of "forbidden PLMNs for non-3GPP access to 5GCN" contains no PLMN in the visited country:
– if the home N3IWF identifier configuration is provisioned in the N3AN node configuration information (see 3GPP TS 24.526 [17]) and contains an IP address, the UE shall use the IP address of the home N3IWF identifier configuration as the IP address of the N3IWF;
– if the home N3IWF identifier configuration is provisioned in the N3AN node configuration information (see 3GPP TS 24.526 [17]) and does not contains an IP address, the UE shall use the FQDN of the home N3IWF identifier configuration as N3IWF FQDN; and
– if the home N3IWF identifier configuration is not provisioned in the N3AN node configuration information, the UE shall construct an N3IWF FQDN based on the Operator Identifier FQDN format using the PLMN ID of the HPLMN as described in clause 28 of 3GPP TS 23.003 [8];
and for the above cases constructing or using an N3IWF FQDN, the UE shall use the DNS server function to resolve the N3IWF FQDN to the IP address(es) of the N3IWF(s). The UE shall select as the IP address of the N3IWF a resolved IP address of an N3IWF with the same IP version as its local IP address; and
iii) if no DNS response is received, the UE shall terminate the N3AN node selection procedure.
Following bullet a) and b) above, once the UE selected the IP address of the N3IWF:
a) if the IP address of N3IWF is selected, the UE shall:
1) initiate the IKEv2 SA establishment procedure as specified in clause 7.3;
2) if the IKEv2 SA establishment procedure towards an N3IWF in the HPLMN fails due to no response to an IKE_SA_INIT request message, and the selection of N3IWF in the HPLMN is performed using home N3IWF identifier configuration and there are more pre-configured N3IWFs in the HPLMN, repeat the tunnel establishment attempt using the next FQDN or IP address(es) of the N3IWF in the HPLMN;
3) if the IKEv2 SA establishment procedure towards any of the IP addresses of the N3IWF of the selected PLMN fails due to no response to an IKE_SA_INIT request message, repeat the N3AN node selection as described in this clause with N3IWF of another PLMN;
4) if the IKEv2 SA establishment procedure towards any of the received IP addresses of the N3IWF of any fails due to no response to an IKE_SA_INIT request message, attempt to select an ePDG as specified in 3GPP TS 24.302 [7] and use tunnel establishment as specified in 3GPP TS 24.302 [7]; and
5) if the UE fails to connect to either N3IWF or ePDG in the VPLMN with which it is registered via 3GPP access, the UE considers the N3AN node selection information entry for the VPLMN as not present in the N3AN node selection information and the UE shall repeat the N3IWF selection as described in this clause;
NOTE 1: The time the UE waits before reattempting access to another N3IWF or to an N3IWF that it previously did not receive a response to an IKE_SA_INIT request message, is implementation specific.
b) if the IP address of ePDG is selected, the UE shall:
i) initiate tunnel establishment as specified in 3GPP TS 24.302 [7];
ii) if tunnel establishment as specified in 3GPP TS 24.302 [7] towards an ePDG in the HPLMN fails due to no response to an IKE_SA_INIT request message, and the selection of ePDG in the HPLMN is performed using home ePDG identifier configuration and there are more pre-configured ePDG in the HPLMN, repeat the tunnel establishment attempt using the next FQDN or IP address(es) of the ePDG in the HPLMN;
iii) if tunnel establishment as specified in 3GPP TS 24.302 [7] towards any of the received IP addresses of the selected ePDG fails due to no response to an IKE_SA_INIT request message, attempt to select an N3IWF in the same PLMN instead;
iv) if the UE fails to connect to either ePDG or N3IWF in the same PLMN, repeat the N3AN node selection as described in this clause, excluding the ePDGs for which the UE did not receive a response to the IKE_SA_INIT request message; and
v) if the UE fails to connect to either ePDG or N3IWF in the VPLMN with which it is registered via 3GPP access, the UE considers the N3AN node selection information entry for the VPLMN as not present in the N3AN node selection information and the UE shall repeat the N3IWF selection as described in this clause.
NOTE 2: The time the UE waits before reattempting access to another ePDG or to an ePDG that it previously did not receive a response to an IKE_SA_INIT request message, is implementation specific.
7.2.5 Selection of an N3AN node in an SNPN
In order to access SNPN services via a PLMN, an SNPN enabled UE is configured with an N3IWF FQDN for the SNPN and with an MCC of the country where the configured N3IWF is located. To select an N3IWF in an SNPN, the UE shall first determine the country in which the UE is located. If the UE cannot determine the country in which the UE is located, the UE shall stop the SNPN N3IWF selection. If the UE can determine the country in which the UE is located, the UE shall proceed as follows:
NOTE 1: It is up to UE implementation how the UE determines the country in which the UE is located.
a) if the UE is located in the country where the configured N3IWF is located, the UE shall use the configured N3IWF FQDN for the SNPN N3IWF selection; or
b) if the UE is located in a country different from the country where the configured N3IWF is located:
1) the UE shall construct a Visited Country FQDN for SNPN N3IWF selection as specified in 3GPP TS 23.003 [8]; and
2) the UE shall perform the DNS NAPTR query using the constructed Visited Country FQDN for SNPN N3IWF selection. If:
i) the result of this DNS query includes:
A) a set of one or more records, the UE shall select an N3IWF FQDN included in the DNS response based on UE implementation means and use the selected N3IWF FQDN for the SNPN N3IWF selection; or
NOTE 2: If the visited country mandates the selection of the N3IWF in this country and the SNPN does not have the N3IWF in this country, DNS resolution of the selected N3IWF FQDN provides no IP addresses, resulting into stop of the SNPN N3IWF selection.
NOTE 3: The identity (i.e. in the corresponding DNS record) of an SNPN’s N3IWF in the visited country can be any FQDN and is not required to include the SNPN identity.
B) no records, the UE shall use the configured N3IWF FQDN for the SNPN N3IWF selection; or
ii) there is no response to the DNS query, the UE shall stop the SNPN N3IWF selection.
7.2.6 N3AN node selection for emergency services
7.2.6.1 General
If the UE is connected to an N3IWF that is in the same country as the country in which the UE is currently in and the AMF has previously indicated support for emergency services over non-3GPP access (see 3GPP TS 24.501 [4]), the UE shall use the existing N3IWF connection for emergency services. Otherwise, the UE shall perform the IKEv2 deletion procedure for the existing N3IWF connection and initiate N3AN node selection procedure for emergency services as described below.
When the UE supports connectivity with N3IWF but does not support connectivity with ePDG, the UE shall perform the procedure in clause 7.2.6.2 for selecting an N3IWF for emergency services.
When the UE supports connectivity with N3IWF and ePDG, the UE shall perform the procedure in clause 7.2.6.3 for selecting either an N3IWF or an ePDG for emergency services.
7.2.6.2 UE procedure when the UE only supports connectivity with N3IWF
If the UE is in the home country, the UE shall follow the procedure in clause 7.2.4.3 bullet a).
If the UE is in a visited country, the UE shall perform the DNS NAPTR query using Visited Country Emergency N3IWF FQDN as specified in 3GPP TS 23.003 [8] via the non-3GPP access network to determine PLMNs in the visited country that support emergency services in non-3GPP access via N3IWF. If the DNS response contains one or more records, the UE shall select a PLMN included in the DNS response that has highest PLMN priority (see 3GPP TS 24.526 [17]) in the N3AN node selection information, excluding any PLMN in the list of "forbidden PLMNs for non-3GPP access to 5GCN". The UE shall construct an N3IWF FQDN based on the FQDN format of the selected PLMN’s N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the selected PLMN as specified in 3GPP TS 23.003 [8]. If none of the PLMNs included in the DNS response figures in the N3AN node selection information or the N3AN node selection information is not provisioned, the UE shall select any of the PLMNs included in the DNS response and shall construct an N3IWF FQDN based on the Operator Identifier based N3IWF FQDN format.
If the emergency registration procedure has failed for all attempted PLMNs, or the DNS response in the visited country does not contain any record, the UE shall abort the procedure.
NOTE: The UE can notifiy the user that an emergency session cannot be established.
7.2.6.3 UE procedure when the UE supports connectivity with N3IWF and ePDG
If the UE is in the home country, the UE shall follow the steps in clause 7.2.4.4.2 bullet a), except that:
– in bullet a)1)i), if the emergency registration fails, the UE shall attempt to select an ePDG in the home country using the steps under bullet a)1)ii); and
– in bullet a)1)ii):
– Emergency ePDG FQDN shall be used instead of home ePDG identifier; and
– If the emergency registration fails, the UE shall attempt to select an N3IWF in the home country using the steps under bullet a)1)i).
If the UE is in a visited country, the UE shall perform the DNS NAPTR query using Visited Country Emergency N3IWF FQDN and Visited Country Emergency FQDN as specified in 3GPP TS 23.003 [8] via the non-3GPP access network to determine PLMNs in the visited country that support emergency services in non-3GPP access via N3IWF or ePDG. If the DNS response contains one or more records, the UE shall select a PLMN included in the DNS response that has highest PLMN priority (see 3GPP TS 24.526 [17]) in the N3AN node selection information.
– If the N3AN node selection information for the PLMN is available the UE selects first an N3IWF or ePDG based on the the preference parameter in the selected PLMN’s N3AN node selection information entry of the N3AN node selection information. If N3IWF is preferred, the UE constructs the N3IWF FQDN based on the FQDN format of the selected PLMN’s N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the selected PLMN as specified in 3GPP TS 23.003 [8]. If ePDG is preferred, the UE constructs either the Tracking/Location Area Identity based Emergency ePDG FQDN or the Operator Identifier based Emergency ePDG FQDN as indicated by the FQDN format in the N3AN node selection information for the selected PLMN.
– If the N3AN node selection information is not available, the UE shall follow the procedure in clause 7.2.6.2, except that, instead of aborting the procedure in case of a failure, the UE shall perform the procedure for ePDG selection for emergency services specified in 3GPP TS 24.302 [7], by constructing the Operator Identifier based Emergency ePDG FQDN.
If the emergency registration procedure has failed for all attempted PLMNs, the UE shall abort the procedure.
7.3 IKE SA establishment procedure for untrusted non-3GPP access
7.3.1 General
The purpose of this procedure is to establish a secure connection between the UE and the N3IWF over NWu, which is used to securely exchange the NAS signalling messages between the UE and the AMF via the N3IWF. The UE establishes the secure connection by establishing an IKE SA and first child SA to the N3IWF. The IKE SA and first child SA, called signalling IPsec SA, are created between the UE and the N3IWF after the IKE_SA_INIT exchange and after the IKE_AUTH exchange (see IETF RFC 7296 [6]). The signalling IPsec established is used to transfer NAS signalling traffic. Additional child SAs (user plane IPsec SAs) can be established between the UE and the N3IWF to transfer user-plane traffic (see clause 7.5).
Upon completion of the N3IWF selection procedure (clause 7.2) the UE initiates an IKE_SA_INIT exchange as specified in IETF RFC 7296 [6]. Upon reception of the IKE_SA_INIT response the UE shall inform the upper layers that the access stratum connection is established.
Upon establishment of the access stratum connection, the UE initiates IKE_AUTH exchange (see IETF RFC 7296 [6]) with EAP-5G encapsulation, as specified in clause 7.3.2.
The UE encapsulates the initial NAS message and the AN parameters using the EAP-5G procedure as described in clause 7.3.3. The signalling IPsec SA is established after completion of the EAP-5G procedure and IKE_AUTH exchange.
7.3.2 IKE SA and signalling IPsec SA establishment procedure
7.3.2.1 IKE SA and signalling IPsec SA establishment initiation
The UE proceeds with the establishment of IKE SA and signalling IPsec SA with the selected N3IWF by initiating an IKE_SA_INIT exchange according to IETF RFC 7296 [6]. All the IKE messages following the IKE_SA_INIT exchange are encrypted and integrity protected using the cryptographic algorithms and keys negotiated in the IKE_SA_INIT exchange as specified in IETF RFC 7296 [6].
Upon completion of the IKE_SA_INIT exchange, the UE shall initiate an IKE_AUTH exchange as specified in IETF RFC 7296 [6] to establish an IKE SA and first child SA (signalling IPsec SA).. In the initial IKE_AUTH request message, the UE shall:
– indicate the intention to use EAP by not including the AUTH payload;
– include the IDi payload with the ID type set to ID_KEY_ID and value set to any random number; and
– include CERTREQ payload to request N3IWF’s certificate if the UE is provisioned with the N3IWF root certificate,
as specified in IETF RFC 7296 [6].
Upon reception of the IKE_AUTH request message, the N3IWF shall respond with an IKE_AUTH response message including:
– an EAP-Request/5G-Start packet to inform the UE an EAP-5G session that will be used to convey the initial NAS messages (see the EAP-5G procedure described in clause 7.3.3);
– the IDr payload with the value set to N3IWF identity; and
– the CERT payload containing the N3IWF’s certificate if the CERTREQ payload is included in the IKE_AUTH request message.
7.3.2.2 IKE SA and signalling IPsec SA establishment accepted by the network
If IKE SA and signalling IPsec SA establishment is accepted by the network, the UE receives from the N3IWF an IKE_AUTH response message containing an EAP-Success message (as shown in figure 7.3.2-1), which completes the EAP-5G session. No further EAP-5G packets are exchanged.
The UE completes the IKE SA and signalling IPsec SA (first child SA) establishment procedure by initiating an IKE_AUTH exchange including an AUTH payload computed based on the N3IWF key as described in 3GPP TS 33.501 [5]. In the IKE_AUTH request message the UE additionally shall include:
– the INTERNAL_IP4_ADDRESS attribute, the INTERNAL_IP6_ADDRESS attribute, or both, indicating the type of IP address to be used for the IP tunnels, in the CFG_REQUEST configuration payload. The INTERNAL_IP4_ADDRESS attribute shall contain no value and the length field shall be set to 0. The INTERNAL_IP6_ADDRESS attribute shall contain no value and the length field shall be set to 0; and
– the MOBIKE_SUPPORTED notify payload as specified in IETF RFC 4555 [23] if the UE supports IETF RFC 4555 [23].
The N3IWF shall include in the IKE_AUTH response message containing the AUTH payload:
– a single CFG_REPLY Configuration Payload including the INTERNAL_IP4_ADDRESS attribute with an IPv4 address assigned to the UE, the INTERNAL_IP6_ADDRESS attribute with an IPv6 address assigned to the UE, or both;
– the NAS_IP4_ADDRESS notify payload with an N3IWF IPv4 address assigned to transport of NAS messages, if the initial IKE_AUTH request message contained a CFG_REQUEST configuration payload with the INTERNAL_IP4_ADDRESS attribute and NAS messages are to be transmitted using IPv4 based inner IP tunnel;
– the NAS_IP6_ADDRESS notify payload with an N3IWF IPv6 address assigned to transport of NAS messages if the initial IKE_AUTH request message contained a CFG_REQUEST configuration payload with the INTERNAL_IP6_ADDRESS attribute and NAS messages are to be transmitted using IPv6 based inner IP tunnel;
– the NAS_TCP_PORT notify payload with an N3IWF TCP port number assigned to transport of NAS messages; and
– the MOBIKE_SUPPORTED notify payload as specified in IETF RFC 4555 [23], if the initial IKE_AUTH request message contained a MOBIKE_SUPPORTED configuration payload with the INTERNAL_IP4_ADDRESS attribute.
The UE may support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in 3GPP TS 24.302 [7] clause 8.2.4.2. If the UE supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute, the UE shall include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute indicating support of receiving timeout period for liveness check in the CFG_REQUEST configuration payload within the IKE_AUTH request message.
The N3IWF may include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in 3GPP TS 24.302 [7] clause 8.2.4.2 indicating the timeout period for liveness check in the CFG_REPLY configuration payload of the IKE_AUTH response message containing the AUTH payload. Presence of the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute in the IKE_AUTH request can be used as input for decision on whether to include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute in the IKE_AUTH response message containing the AUTH payload.
If the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in 3GPP TS 24.302 [7] clause 8.2.4.2 indicating the timeout period for the liveness check is included in the CFG_REPLY configuration payload within the IKE_AUTH response message containing the AUTH payload or the UE has a pre-configured or configured timeout period, the UE shall perform the liveness check procedure as described in clause 7.8.
NOTE: The timeout period for liveness check is pre-configured in the UE in implementation specific way.
This completes the establishment of the IKE SA and signalling IPsec SA (first child SA) between the UE and the N3IWF. Upon completion of the IKE SA and signalling IPsec SA (first child SA) establishment between the UE and the N3IWF, the UE and the N3IWF shall send further NAS messages over the TCP connection within the signalling IPsec SA (first child SA) (see example in figure 7.3.2.2-1).
An example of an IKE SA and first child SA establishment procedure is shown in figure 7.3.2.2-1.
Figure 7.3.2.2-1: IKE SA and first child SA establishment procedure for UE registration over untrusted non-3GPP access
7.3.2.3 IKE SA and signalling IPsec SA establishment not accepted by the network
If IKE SA and signalling IPsec SA establishment is not accepted by the network, the UE receives from the N3IWF an IKE_AUTH response message including a Notify payload with an error type.
Upon receiving the IKE_AUTH response message with a Notify payload with an error type other than a CONGESTION Notify payload, the UE shall pass the error indication to the upper layer along with the encapsulated NAS messages, if any, within EAP/5G-NAS packet.
After the N3IWF receives from the UE an IKE_AUTH request message, the N3IWF shall construct an IKE_AUTH response message including a CONGESTION Notify payload as defined in clause 9.2.4.2 and a N3GPP_BACKOFF_TIMER Notify payload as defined in clause 9.3.1.7. if the N3IWF decides to not accept the IKE SA and signalling IPsec SA establishment based on the OVERLOAD START message received from the AMF(s) as specified in 3GPP TS 29.413 [39].
NOTE: The N3IWF can also due to internal congestion construct an IKE_AUTH response message including a CONGESTION Notify payload as defined in clause 9.2.4.2 and a N3GPP_BACKOFF_TIMER Notify payload as defined in clause 9.3.1.7 and send it to the UE.
The N3IWF shall send the IKE_AUTH response message to the UE.Upon reception of the IKE_AUTH response message including:
a) a CONGESTION Notify payload as defined in clause 9.2.4.2; and
b) a N3GPP_BACKOFF_TIMER Notify payload as defined in clause 9.3.1.7; and
after the UE authenticates the network or the N3IWF as specified in 3GPP TS 33.501 [5], the UE shall discard all states associated with the IKE SA and any child SAs that were negotiated using that IKE SA as specified in IETF RFC 7296 [6]. In addition, the UE shall inform the upper layers that the access stratum connection has been released, and:
a) if the back-off timer value in N3GPP_BACKOFF_TIMER Notify payload indicates neither zero nor deactivated, the UE shall start the Tw3 timer with the value provided and the UE shall not retry the IKE SA and signalling IPsec SA establishment procedure to the same N3IWF until:
– timer Tw3 expires;
– the UE is switched off;
– the UICC containing the USIM is removed;
– an access attempt occurs due to emergency services; or
– the UE needs to request one or more S-NSSAIs that were not included in the requested NSSAI provided to the N3IWF previously;
b) if the back-off timer value in N3GPP_BACKOFF_TIMER Notify payload indicates that this timer is deactivated, the UE shall not retry the IKE SA and signalling IPsec SA establishment procedure to the same N3IWF until:
– the UE is switched off;
– the UICC containing the USIM is removed;
– an access attempt occurs due to emergency services; or
– the UE needs to request one or more S-NSSAIs that were not included in the requested NSSAI provided to the N3IWF previously; and
c) if the back-off timer value in N3GPP_BACKOFF_TIMER Notify payload indicates zero, the UE may retry the IKE SA and signalling IPsec SA establishment procedure to an N3IWF from the same PLMN.
Upon receiving the IKE_AUTH response message with a Notify payload with an error type, if the EAP-5G session establishment has already been started, the UE shall perform a local termination of the EAP-5G session.
7.3.3 EAP-5G session over non-3GPP access
7.3.3.1 General
A vendor-specific EAP method (EAP-5G) is used to encapsulate NAS messages between the UE and the N3IWF. The EAP-5G packets utilize the "Expanded" EAP type and the existing 3GPP Vendor-Id registered with IANA under the SMI Private Enterprise Code registry (i.e. 10415). The EAP-5G method is utilized only for encapsulating the NAS messages. The EAP-5G method is not utilized to authenticate the UE in untrusted non-3GPP network.
7.3.3.1A EAP-5G session initiation
The UE and the N3IWF shall exchange EAP-5G messages within IKE_AUTH request and IKE_AUTH response messages. The N3IWF on reception of an IKE_AUTH request with no AUTH payload shall start an EAP-5G session by sending an EAP-Request/5G-Start message.
The UE acknowledges start of the EAP-5G session by sending an EAP-Response/5G-NAS message which shall include:
a) a NAS-PDU field containing a NAS message, for example, a REGISTRATION REQUEST message; and
b) an AN-parameters field containing access network parameters, such as GUAMI, selected PLMN ID, requested NSSAI, establishment cause, selected NID if the UE is accessing SNPN services via a PLMN or the UE is accessing SNPN services via untrusted non-3GPP access network, and onboarding indication if the UE is accessing SNPN for onboarding services in SNPN via untrusted non-3GPP access network (see 3GPP TS 23.502 [3]).
NOTE 1: If and how the UE includes the requested NSSAI as a part of the access type depends on the NSSAI inclusion mode IE as specified in 3GPP TS 24.501 [4].
The N3IWF, on reception of NAS messages from the UE within an EAP-Response/5G-NAS message, shall forward the NAS message to the AMF.
The N3IWF, on reception of NAS messages from the AMF, shall include the NAS message within an EAP-Request/5G-NAS message. The N3IWF shall transmit the EAP-Request/5G-NAS message to the UE.
NOTE 2: The N3IWF is transparent to the NAS messages and as an intermediate network entity only conveys transparently the NAS messages between the UE and the AMF.
The EAP-Request/5G-NAS message shall include a NAS-PDU field that contains a NAS message.
Further NAS messages between the UE and the AMF, via the N3IWF, shall be inserted in NAS-PDU field of an EAP-Response/5G-NAS (UE to N3IWF direction) and EAP-Request/5G-NAS (N3IWF to UE direction) message.
7.3.3.2 EAP-5G session completion initiated by the network
Upon completion of successful authentication and on reception of the N3IWF key from the AMF, the N3IWF shall complete the EAP-5G session by sending an EAP-Success message.
On reception of the EAP-Success message from the N3IWF, the UE proceeds to establish an IKE SA and signalling IPsec SA as described in clause 7.3.2.
An example of an EAP-5G session after successful authentication is shown in figure 7.3.3.2-1.
Figure 7.3.3.2-1: EAP-5G session for successful UE registration over untrusted non-3GPP access
7.3.3.3 EAP-5G session completion initiated by the UE
Upon receiving indication from the upper layer that no 5G-NAS messages need to be transmitted between the UE and N3IWF, the UE shall terminate the EAP-5G session by sending an EAP-Response/5G-Stop message to the N3IWF.
On reception of EAP-Response/5G-Stop message, the N3IWF shall complete the EAP-5G session by sending an EAP-Failure message to the UE.
On reception of the EAP-Failure message from the N3IWF, the UE shall delete any context related to IKE SA without requiring an explicit INFORMATIONAL exchange carrying a Delete payload as specified in IETF RFC 7296 [6].
Figure 7.3.3.3-1 shows an example the EAP-5G session completion after registration reject.
Figure 7.3.3.3-1: EAP-5G session when the UE’s registration over untrusted non-3GPP access is rejected
7.3.4 Abnormal cases in the UE
Apart from the cases specified in IETF RFC 7296 [6], no abnormal cases have been identified.
7.3.5 Abnormal cases in the N3IWF
Apart from the cases specified in IETF RFC 7296 [6], no abnormal cases have been identified.
7.3A IKE SA establishment procedure for trusted non-3GPP access
7.3A.1 General
A trusted non-3GPP access network (TNAN) includes a trusted non-3GPP access point (TNAP) and a trusted non-3GPP gateway function (TNGF). The TNAN and a UE initiate an exchange of EAP-Request and EAP-Response messages including Identity as specified in IETF RFC 3748 [9] for link layer authentication of the UE by the TNAP. Upon completion of the EAP-Request/Response messages, an exchange of the EAP-5G messages are initiated once the UE receives an EAP-Request/5G-Start from the TNGF. The UE also at that time informs the upper layers that the access stratum connection is established.
An exchange of the NAS messages which are encapsulated in EAP-5G messages occur until the UE is authenticated by the 5GCN. Upon completion of the UE authentication and reception of the EAP-Success by the UE, the UE and the TNAP employs the TNAP key to establish access specific layer-2 security such as 4-way handshake in case IEEE 802.11 [19] is used between the TNAP and the UE.
Upon completion of successful establishment of access specific layer-2 security, the UE is configured with an IP address by TNAN by e.g. DHCP and the UE initiates an IKE_SA_INIT exchange as specified in IETF RFC 7296 [6].
The UE establishes the IP based secure connection by establishing an IKE SA and first child SA for NAS signalling traffic to the TNGF over NWt. Once the UE establishes the IKE SA and the signalling IPsec SA with the TNGF, the UE initiates establishment of a TCP connection for transport of NAS message with TNGF, secured using the signalling IPsec SA. The UE and the TNGF exchanges NAS messages over the TCP connection once it is established. Additional child SAs (user plane IPsec SAs) can be established to transfer user plane traffic (see clause 7.5).
An example of an IKE SA and first child SA establishment procedure is shown in figure 7.3A.1-1.The figure illustrates that EAP messages are employed for the communication between the UE and the TNAP while the TNAP is transparent to the communication between the UE and the TNGF when employing EAP-5G messages. Link layer protocol is used to exchange these messages between the UE and the TNAN. The internal protocol used for the communications between the TNAP and the TNGF, is illustrated as dashed lines in this figure and is out of the scope of 3GPP.
Figure 7.3A.1-1: IKE SA and first child SA establishment procedure for UE registration over trusted non-3GPP access
7.3A.2 EAP session over non-3GPP access
7.3A.2.1 General
The UE and the TNAN establishes a connection depending on the access link between the UE and the TNAP. For instance if the TNAP is a trusted WLAN access point, IEEE 802.11 [19] describes the connection between the UE and the TNAP. If the access link between the UE and the TNAP is Point-to-Point Protocol (PPP) as specified in IETF RFC 1661 [32], the Link Control Protocol (LCP) as specified in IETF RFC 1570 [33] describes the connection between the UE and the TNAP.
In the trusted non-3GPP access network:
a) the TNAP and the UE exchange EAP-request/Identity message and EAP-response/Identity message; and
b) the TNGF and the UE exchange EAP messages of EAP-5G method,
encapsulated in the link layer protocol packets such as IEEE 802.11/802.1x packets or PPP packets until successful authentication of the UE by the AMF. The link layer protocol packets are transmitted between the UE and the TNAN.
The EAP-5G method is utilized for encapsulating the NAS message to initiate the UE registration to the AMF via the TNGF. As described in clause 7.3.3, the EAP-5G packets utilize the "Expanded" EAP type and the existing 3GPP Vendor-Id registered with IANA under the SMI Private Enterprise Code registry (i.e. 10415).
7.3A.2.2 Identity transaction
Upon reception of EAP-Request/Identity message (as described in IETF RFC 3748 [9]), encapsulated in the link layer protocol packets from the TNAP, the UE shall:
a) construct an EAP-Response/Identity message as described in IETF RFC 3748 [9] containing an NAI as specified in clause 28.7.6 of 3GPP TS 23.003 [8] to request a PLMN or SNPN when the trusted connectivity is 5G connectivity using trusted non-3GPP access; and
b) transmit the EAP-Response of identity type encapsulated in the link layer protocol packets towards the TNAP.
7.3A.2.3 EAP-5G session initiation
The UE and the TNGF shall exchange EAP-5G messages. The TNGF on reception of the NAI by TNAP and passed on to TNGF, shall initiate EAP-5G session by sending an EAP-Request/5G-Start message. Upon reception of an EAP-Request/5G-Start message, the UE shall send an EAP-Response/5G-NAS message encapsulated in link layer protocol packets. In the EAP-Response/5G-NAS message, the UE:
a) shall include a NAS-PDU field containing a NAS message, for example, a REGISTRATION REQUEST message;
b) shall include an AN-parameters field containing access network parameters, such as UE identity, selected PLMN ID or SNPN, requested NSSAI and establishment cause, selected NID if the UE is accessing SNPN services via trusted non-3GPP access network, and onboarding indication if the UE is accessing SNPN for onboarding services in SNPN via trusted non-3GPP access network, see 3GPP TS 23.502 [3], each of which is up to 255 (decimal) octets long; and
NOTE 1: If and how the UE includes the requested NSSAI as a part of the access type depends on the NSSAI inclusion mode IE as specified in 3GPP TS 24.501 [4].
c) if at least one access network parameter is longer than 255 (decimal) octets, shall include an extended-AN-parameters field containing one or more access network parameters, such as UE identity, see 3GPP TS 23.502 [3], each of which is longer than 255 (decimal) octets.
The UE identity shall be 5GS mobile identity of type 5G-GUTI, if available, otherwise it shall be the 5GS mobile identity of type SUCI. The 5GS mobile identities of type 5G-GUTI and of type SUCI are specified in 3GPP TS 24.501 [4].
The TNGF on reception of EAP-Response/5G-NAS message, forwards the NAS message to the AMF.
NOTE 2: The TNGF is transparent to the NAS messages and as an intermediate network entity only conveys transparently the NAS messages to the AMF.
The TNAN, on reception of the NAS messages from the AMF, shall send an EAP-Request/5G-NAS message encapsulated in the link layer protocol packets towards the UE via the TNAP.
The EAP-Request/5G-NAS message shall include a NAS-PDU field that contains a NAS message. Further NAS messages between the UE and the AMF, via the TNGF, shall be inserted in NAS-PDU field of an EAP-Response/5G-NAS (UE to TNGF direction) and EAP-Request/5G-NAS (TNGF to UE direction) message.
The UE, on reception of the EAP-Request/5G-NAS message including a NAS-PDU field containing a NAS message e.g. for security establishment, shall send a response with EAP-Response/5G-NAS message including a NAS-PDU field containing a NAS message related to the NAS security context to the TNGF.
The TNGF, on reception of the TNGF key shall construct an EAP-Request/5G-Notification message that includes an AN-parameters field containing the access network parameters, such as TNGF IPv4 contact information, TNGF IPv6 contact information, or both, see 3GPP TS 23.502 [3]. The TNGF shall send the EAP-Request/5G-Notification message encapsulated in the link layer protocol packets towards the UE via the TNAP. The UE shall acknowledge by sending an EAP-Response/5G-Notification message encapsulated in the link layer protocol packets.
7.3A.2.4 EAP-5G session completion initiated by the network
Upon completion of successful authentication and on reception of the acknowledgement from the UE that it had received the access network parameters, the TNAN shall send an EAP-Success message encapsulated in the link layer protocol packets towards the UE via the TNAP.
7.3A.2.5 EAP-5G session completion initiated by the UE
For trusted non-3GPP access, the procedure for when the EAP-5G session completion initiated by the UE, is the same as that of untrusted non-3GPP access as described in clause 7.3.3.3 with the difference that the N3IWF shall be replaced by the TNGF.
7.3A.3 IKE SA and signalling IPsec SA establishment procedure
7.3A.3.1 IKE SA and signalling IPsec SA establishment initiation
In a trusted non-3GPP access network, once the EAP- 5G authentication is successfully complete and the UE is configured with a local IP address, the UE shall use the TNGF IP address received in the EAP-Request/5G-Notification message (see clause 7.3A.2.3) to establish a secure connection between the UE and the TNGF over NWt to exchange NAS signalling messages with the AMF. The UE shall establish the secure connection by establishing an IKE SA and signalling IPsec SA (first child SA) by initiating the IKE_SA_INIT exchange and then IKE_AUTH exchange for mutual authentication with the TNGF and NULL encryption as specified in IETF RFC 2410 [34]. The UE shall set the IDi payload of the IKE_AUTH request message in the IKE_AUTH exchange (see IETF RFC 7296 [6]) to the NAI format of 5G-GUTI or the NAI format of SUCI as specified in 3GPP TS 23.003 [8], depending on the employed UE identity in the EAP-Response/5G-NAS message at the time of EAP-5G session initiation according to clause 7.3A.2.3.
7.3A.3.2 IKE SA and signalling IPsec SA establishment accepted by the network
The UE shall establish the IKE SA and signalling IPsec SA (first child SA) according to clause 7.3.2.2 with the difference that the N3IWF is replaced by the TNGF.
Upon completion of the IKE SA and signalling IPsec SA (first child SA) establishment between the UE and the TNGF, the UE and the TNGF shall send further NAS messages over the TCP connection within the signalling IPsec SA (first child SA).
7.3A.3.3 IKE SA and signalling IPsec SA establishment not accepted by the network
For trusted non-3GPP access, the procedure for when the IKE SA and signalling IPsec SA establishment are not accepted by the network, is the same as that of the untrusted non-3GPP access as described in clause 7.3.2.3 with the difference that the N3IWF shall be replaced by the TNGF.
7.3A.4 Procedure for devices without NAS support
7.3A.4.1 General
A trusted non-3GPP access network (TNAN) may be implemented as a trusted WLAN access network (TWAN) which supports a WLAN access technology such as the one described in IEEE 802.11 [19]. A non 5G capable over WLAN (N5CW) device does not support NAS signalling with the 5GCN over WLAN, but may access 5GCN via a TWAN supporting a trusted WLAN interworking function (TWIF). An N5CW device may be a UE with capability for NAS signalling with the 5GCN using the N1 reference point as specified in 3GPP TS 24.501 [4] over 3GPP access although it lacks capability of NAS signalling over WLAN.
7.3A.4.2 N5CW device registration over trusted WLAN access network
A trusted WLAN access network (TWAN) includes a trusted WLAN access point (TWAP) and a trusted WLAN interworking function (TWIF) as illustrated in figure 7.3A.4.2-1.
|
|
Figure 7.3A.4.2-1: Trusted WLAN Access Network
The EAP-AKA’ authentication procedure is executed for connecting the N5CW device to a TWAN according to 3GPP TS 33.501 [5] clause 7A.2.4.
The TWAN and an N5CW device initiate an exchange of EAP-Request/Identity message and EAP-Response/Identity message as specified in IETF RFC 3748 [9] for link layer authentication of the UE by the TWAP. In the trusted WLAN access network, the TWAP and the N5CW device exchange EAP-Request/Identity message and EAP-Response/Identity message, encapsulated in the link layer protocol packets i.e. IEEE 802.11/802.1x packets.
Upon reception of EAP-Request/Identity message encapsulated in the IEEE 802.11/802.1x packets from the TWAP, the N5CW device shall:
a) construct an EAP-Response/Identity message as described in IETF RFC 3748 [9] containing an NAI as specified in clause 28.7.7 of 3GPP TS 23.003 [8] to request a PLMN or SNPN when the trusted connectivity is 5G connectivity without NAS using trusted non-3GPP access; and
NOTE 1: The NAI includes the 5G-GUTI assigned to the N5CW device over 3GPP access, if the N5CW device is also a UE and is already registered to 5GCN over 3GPP access. If the N5CW device is not registered to the 5GCN over 3GPP access, the NAI includes the SUCI. The NAI includes the SUCI if the N5CW device is also a 5G UE and has not registered to 5GCN over 3GPP access.
b) transmit the EAP-Response of identity type encapsulated in the link layer protocol packets towards the TWAP.
The TWAP conveys the information provided by the N5CW device to the TWIF which initiates a registration procedure followed by a PDU session establishment procedure to obtain an IP address, on behalf of the N5CW device to an AMF according to 3GPP TS 24.501 [4].
NOTE 2: The communication protocol between the TWAP and the TWIF is outside of the scope of 3GPP.
An exchange of the EAP request and EAP response as described in IETF RFC 3748 [9] occurs until the N5CW device is authenticated by the 5GCN with the EAP authentication described in 3GPP TS 33.501 [5]. Upon completion of the N5CW device authentication and reception of the EAP-Success by the N5CW device, the N5CW device and the TWAP use the TWAP key to establish access specific layer-2 security 4-way handshake according to IEEE 802.11 [19].
7.4 IKEv2 SA deletion procedure
7.4.1 General
The purpose of the IKE SA deletion procedure via untrusted non-3GPP access and trusted non-3GPP access is to close the IKE SA between the UE and the N3IWFfor untrusted non-3GPP access and the TNGF for trusted non-3GPP access. In addition, deleting the IKE SA implicitly closes any remaining signalling IPsec child SAs and user plane IPsec child SAs associated with IKE SA.
This procedure shall be initiated either by the N3IWF, TNGF or by the UE.
The N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access initiate this procedure in the following cases:
a) N1 NAS signalling connection release;
b) N3IWF-initiated and TNGF-initiated IKE SA rekeying procedure failure;
c) N3IWF-initiated and TNGF-intiated IKE SA rekeying procedure completion
d) upon receipt of an INITIAL_CONTACT notification as specified in IETF RFC 7296 [6]; and
e) upon detecting an error in a response packet as specified in IETF RFC 7296 [6].
The UE initiates this procedure in the following cases:
a) UE-initiated IKE SA rekeying procedure failure;
b) UE-initiated IKE SA rekeying procedure completion;
c) upon receipt of an INITIAL_CONTACT notification as specified in IETF RFC 7296 [6]; and
d) upon detecting an error in a response packet as specified in IETF RFC 7296 [6].
NOTE: UE can also initiate the IKE SA deletion procedure, based on implementation, in abnormal scenarios e.g. a local release of N1 NAS signalling connection upon expiry of T3540 and UE fails to receive INFORMATIONAL request for IKE SA deletion from the network.
7.4.2 IKE SA deletion procedure initiated by the N3IWF and the TNGF
7.4.2.1 IKE SA deletion initiation
The N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall initiate the IKE SA deletion procedure by sending an INFORMATIONAL request message including a Delete payload to the UE as specified in IETF RFC 7296 [6].
The Delete payload shall be defined with the Protocol ID set to "1" and no SPIs included in the Security Parameter Index field in the Delete payload. This indicates that the IKE security association and all IPsec ESP security associations that were negotiated within the IKE security association between:
a) the N3IWF for untrusted non-3GPP access; and
b) the TNGF for trusted non-3GPP access;
and the UE shall be deleted.
7.4.2.2 IKE SA deletion accepted by the UE
Upon reception of the INFORMATIONAL request message from the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access for deletion of the IKE SA, if the UE accepts the IKE SA deletion request, the UE shall send an empty INFORMATIONAL response message to the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access as specified in IETF RFC 7296 [6].
After sending the empty INFORMATIONAL response message, the UE shall close IKE SA and delete all IPsec child SAs associated with the IKE SA. In addition, the UE shall inform the upper layers that the access stratum connection has been released.
Upon receiving the empty INFORMATIONAL response message, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall close IKE SA and delete all IPsec child SAs associated with the IKE SA. In addition, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall inform the AMF that the access stratum connection has been released.
7.4.2.3 Abnormal cases in the N3IWF and the TNGF
If the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access does not receive any empty INFORMATIONAL response message from the UE, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall discard all states associated with the IKE SA and any child SAs that were negotiated using that IKE SA. In addition, the N3IWF for untrusted non-3GPP access and the TNGF for untrusted non-3GPP access shall inform the AMF that the access stratum connection has been released.
7.4.3 IKE SA deletion procedure initiated by the UE
7.4.3.1 IKE SA deletion initiation
The UE shall initiate the IKE SA deletion procedure by sending an INFORMATIONAL request message including a Delete payload to the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access as specified in IETF RFC 7296 [6].
The Delete payload shall be defined with the Protocol ID set to "1" and no SPIs included in the Security Parameter Index field in the Delete payload. This indicates that the IKE security association and all IPsec ESP security associations that were negotiated within the IKE security association between:
a) the N3IWF for untrusted non-3GPP access; and
b) the TNGF for trusted non-3GPP access;
and the UE shall be deleted.
7.4.3.2 IKE SA deletion accepted by the N3IWF and the TNGF
Upon reception of the INFORMATIONAL request message from the UE for deletion of the IKE SA, if the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access accepts the IKE SA deletion request, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall send an empty INFORMATIONAL response message to the UE as specified in IETF RFC 7296 [6].
After sending the empty INFORMATIONAL response message, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall close the IKE SA and delete all IPsec child SAs associated with the IKE SA. In addition, the N3IWF for untrusted non-3GPP access and theTNGF for trusted non-3GPP access shall inform the AMF that the access stratum connection has been released.
Upon receiving the empty INFORMATIONAL response message, the UE shall close the IKE SA and delete all IPsec child SAs associated with the IKE SA. In addition, the UE shall inform the upper layers that the access stratum connection has been released.
7.4.3.3 Abnormal cases in the UE
If the UE does not receive any empty INFORMATIONAL response message from the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access, the UE shall discard all states associated with the IKE SA and any child SAs that were negotiated using that IKE SA. In addition, the UE shall inform the upper layers that the access stratum connection has been released.
7.5 User plane IPsec SA creation procedure
7.5.1 General
The purpose of the user plane IPsec SA creation procedure is to establish a child SA associating to the QoS flows of the PDU session. This procedure shall be initiated by the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access.
One user plane IPsec SA can be associated with one or more QoS flows of the PDU session. During PDU session establishment or PDU session modification via:
a) untrusted non-3GPP access, the N3IWF; or
b) trusted non-3GPP access, the TNGF,
shall determine the number of user plane IPsec child SAs to establish and the QoS profiles associated with each child SA based on local policies, configuration and the QoS profiles received from the network.
7.5.2 Child SA creation procedure initiation
The N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall initiate the child SA creation procedure by sending a CREATE_CHILD_SA request message to the UE as specified in IETF RFC 7296 [6].
The CREATE_CHILD_SA request message shall include:
a) a UP_IP4_ADDRESS notify payload or a UP_IP6_ADDRESS notify payload; and
b) 5G_QOS_INFO Notify payload as specified in clause 9.3.1.1, which contains:
1) PDU session ID;
2) zero or more QFIs;
3) optionally a DSCP value;
4) optionally an indication of whether the child SA is the default child SA. For a given PDU session ID, there can be only up to one child SA which is the default child SA; and
5) if trusted non-3GPP access, Additional QoS Information or if untrusted non-3GPP access, optionally Additional QoS Information.
The IKE CREATE_CHILD_SA request message also contains the SA payload for the requested child SA.
7.5.3 Child SA creation procedure accepted by the UE
If the UE accepts the CREATE_CHILD_SA request message with a 5G_QOS_INFO Notify payload:
a) the UE shall send a CREATE_CHILD_SA response message as specified in IETF RFC 7296 [6]; and
b) the UE shall associate the created child SA with the:
1) PDU session ID;
2) zero or more QFIs (if indicated);
3) DSCP value (if indicated); and
4) indication of whether the child SA is the default child SA (if indicated);
in the 5G_QOS_INFO Notify payload; and
c) the UE:
1) in case of trusted non-3GPP access, shall reserve non-3GPP access QoS resources for the created child SA based on the received Additional QoS Information; or
2) in case of untrusted non-3GPP access, may reserve non-3GPP access QoS resources for the created child SA if the UE has received Additional QoS Information.
Any IKEv2 Notify payload indicating an error shall not be included in the CREATE_CHILD_SA response message.
7.5.4 Child SA creation procedure not accepted by the UE
If a user plane IPsec SA establishment for a PDU session is not accepted by the UE, the UE shall send a CREATE_CHILD_SA response message to the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access with a Notify payload with error type.
For trusted non-3GPP access, if the UE fails to reserve QoS resources over non-3GPP access for the child SA associated with the QoS flows according to the Additional QoS information in the 5G_QOS_INFO Notify payload, the UE shall include a Notify payload with a Private Notify Message Error Type "NO_RESOURCES_OVER_N3GPP" as defined in clause 9.2.4.2 in the CREATE_CHILD_SA response message.
For untrusted non-3GPP access, if the UE attempts to reserve QoS resources over non-3GPP access for the child SA associated with the QoS flows according to the Additional QoS information in the 5G_QOS_INFO Notify payload but fails the reservation, the UE shall include a Notify payload with a Private Notify Message Error Type "NO_RESOURCES_OVER_N3GPP" as defined in clause 9.2.4.2 in the CREATE_CHILD_SA response message.
Upon receiving the CREATE_CHILD_SA response message with a Notify payload of error type:
– if PDU session establishment over non-3GPP access requires single user plane SA IPsec SA creation, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall stop user plane SA IPsec SA creation procedure and indicate the failure for PDU session establishment over non-3GPP access.
– if PDU session establishment over non-3GPP access requires multiple user plane SA IPsec SA creation, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access may choose to continue user plane SA IPsec SA creation procedure for other user plane IPsec SAs, or stop user plane SA IPsec SA creation procedure and indicate the failure for PDU session establishment over non-3GPP access.
7.5.5 Abnormal cases in the UE
If the UE receives a CREATE_CHILD_SA request message containing a USE_TRANSPORT_MODE notification, the UE shall send a CREATE_CHILD_SA response message to the N3IWF for untrusted non-3GPP access or the TNGF for trusted non-3GPP access without including the USE_TRANSPORT_MODE notification as specified in IETF RFC 7296 [6].
7.5.6 Abnormal cases in the N3IWF and the TNGF
Apart from the cases specified in IETF RFC 7296 [6], no abnormal cases have been identified.
7.6 IPsec SA modification procedure
7.6.1 General
The user plane IPsec child SA modification procedure is to update a child SA associating to the QoS flows of the PDU session. The procedure may be initiated by the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access. The IPsec child SA modification may be accepted or rejected by the UE.
7.6.2 N3IWF and TNGF procedure for IPsec child SA modification
The N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall perform the IPsec child SA modification by sending an INFORMATIONAL request message as specified in IETF RFC 7296 [6] to the UE with an 5G_QOS_INFO Notify payload indicating modified content associated with the IPsec child SA.
7.6.3 UE procedure for IPsec child SA modification
Upon receipt of an INFORMATIONAL request message containing an 5G_QOS_INFO Notify payload:
a) if the content of the 5G_QOS_INFO Notify payload is accepted by the UE, the UE shall:
i) send an empty INFORMATIONAL response message to the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access to acknowledge the reception of the INFORMATIONAL request message; and
ii) update locally the IPsec child SA according to the content of the INFORMATIONAL request message; or
b) if the content of the 5G_QOS_INFO Notify payload is not accepted by the UE, the UE shall:
i) send the reason for rejecting the IPsec SA modification in the content of an INFORMATIONAL response message; and
ii) not update locally the IPsec child SA according to the content of the INFORMATIONAL request message.
For trusted non-3GPP access, if the UE fails to reserve QoS resources over non-3GPP access for the child SA associated with the QoS flows according to the Additional QoS information in the 5G_QOS_INFO Notify payload, the UE shall include a Notify Payload with a Private Notify Message Error Type "NO_RESOURCES_OVER_N3GPP" as defined in clause 9.2.4.2 in the INFORMATIONAL response message.
For untrusted non-3GPP access, if the UE attempts to reserve QoS resources over non-3GPP access for the child SA associated with the QoS flows according to the Additional QoS information in the 5G_QOS_INFO Notify payload but fails the reservation, the UE shall include a Notify Payload with a Private Notify Message Error Type "NO_RESOURCES_OVER_N3GPP" as defined in clause 9.2.4.2 in the INFORMATIONAL response message.
7.7 IPSec SA deletion procedure
7.7.1 General
The purpose of the child SA deletion procedure for PDU session release is to delete all the child SAs associated with the PDU session. This procedure shall be initiated either by the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access or by the UE.
The N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access initiates this procedure in the following cases:
a) upon PDU session release;
b) N3IWF-initiated and TNGF-intiated IPsec SA rekeying procedure failure;
c) N3IWF-initiated and TNGF-intiated IPsec SA rekeying procedure completion; and
d) upon detecting an error in a response packet as specified in IETF RFC 7296 [6].
The UE initiates this procedure in the following cases:
a) UE-initiated IPsec SA rekeying procedure failure;
b) UE-initiated IPsec SA rekeying procedure completion; and
c) upon detecting an error in a response packet as specified in IETF RFC 7296 [6].
7.7.2 N3IWF-initated and TNGF-initiated child SA deletion procedure
7.7.2.1 N3IWF-initiated and TNGF-initiated child SA deletion procedure initiation
The N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall initiate the child SA deletion procedure by sending an INFORMATIONAL request message including a Delete payload to the UE as specified in IETF RFC 7296 [6]. The Delete payload shall include:
a) the Protocol ID set to "3" for ESP; and
b) all the N3IWF’s ESP SPI(s) for untrusted non-3GPP access and all the TNGF’s EPS SPI(s) for trusted non-3GPP access, associated to the released PDU session.
7.7.2.2 N3IWF-initiated and TNGF-initiated child SA deletion procedure accepted by the UE
If the UE accepts the INFORMATIONAL request message for deletion of the child SAs, the UE shall send the INFORMATIONAL response message to the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access including the Delete payload received in the corresponding INFORMATIONAL request message as specified in IETF RFC 7296 [6].
Any IKEv2 Notify payload indicating an error shall not be included in the INFORMATIONAL response message.
7.7.2.3 Abnormal cases in the N3IWF and the TNGF
If the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access does not receive any INFORMATIONAL response message including a Delete payload from the UE, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall discard all states associated with the IKE SA and any child SAs that were negotiated using that IKE SA. In addition, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall inform the AMF that the access stratum connection has been released.
7.7.3 UE-initiated child SA deletion procedure
7.7.3.1 UE-initiated child SA deletion procedure initiation
The UE shall initiate the child SA deletion procedure by sending an INFORMATIONAL request message including a Delete payload as specified in IETF RFC 7296 [6], to the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access. The Delete payload shall include:
a) the Protocol ID set to "3" for ESP; and
b) all the UE’s ESP SPI(s) associated to the released PDU session.
7.7.3.2 UE-initiated child SA deletion procedure accepted by the N3IWF and the TNGF
If the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access accepts the INFORMATIONAL request message for deletion of the child SAs, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall send the INFORMATIONAL response message to the UE including the Delete payload received in the corresponding INFORMATIONAL request message as specified in IETF RFC 7296 [6].
Any IKEv2 Notify payload indicating an error shall not be included in the INFORMATIONAL response message.
7.7.3.3 Abnormal cases in the UE
If the UE does not receive any INFORMATIONAL response message including a Delete payload from the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access, the UE shall discard all states associated with the IKE SA and any child SAs that were negotiated using that IKE SA. In addition, the UE shall inform the upper layers that the access stratum connection has been released.
7.7.4 Abnormal cases in the UE
Apart from the cases specified in IETF RFC 7296 [6] and clause 7.7.3.3, no abnormal cases have been identified.
7.7.5 Abnormal cases in the N3IWF and the TNGF
Apart from the cases specified in IETF RFC 7296 [6] and clause 7.7.2.3, no abnormal cases have been identified.
7.8 UE-initiated liveness check procedure
7.8.1 General
The UE-initiated liveness check procedure enables the UE to detect whether the N3IWF for untrusted non-3GPP access and the TNGFfor trusted non-3GPP access is alive.
7.8.2 UE-initiated liveness check procedure initiation
If the UE supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in 3GPP TS 24.302 [7] clause 8.2.4.2 and the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in 3GPP TS 24.302 [7] clause 8.2.4.2 was included in the CFG_REPLY configuration payload within the IKE_AUTH response message received in clause 7.3 the UE shall set the timeout period for the liveness check to the value of the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute.
If the UE does not support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in 3GPP TS 24.302 [7] clause 8.2.4.2 or the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in 3GPP TS 24.302 [7] clause 8.2.4.2 was not included in the CFG_REPLY configuration payload within the IKE_AUTH response message received in clause 7.3, then the UE shall use the pre-configured value of the timeout period for liveness check.
NOTE: The timeout period is pre-configured in the UE in implementation-specific way.
If the UE has not received any cryptographically protected IKEv2 or IPsec message for the duration of the timeout period for liveness check, the UE shall send an INFORMATIONAL request with no payloads as per IETF RFC 7296 [6].
7.8.3 UE-initiated liveness check procedure completion
The N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall handle the INFORMATIONAL request with no payloads as per IETF RFC 7296 [6] and shall send an INFORMATIONAL response.
If an INFORMATIONAL response is received, the UE shall consider the UE-initiated liveness check procedure as successfully completed.
7.8.4 Abnormal cases
If an INFORMATIONAL response is not received, the UE shall deem the IKEv2 security association to have failed.
The UE shall discard all states associated with the IKE SA and any child SAs that were negotiated using that IKE SA as specified in IETF RFC 7296 [6]. In addition, the UE shall inform the upper layers that the access stratum connection has been released.
7.9 Network-initiated liveness check procedure
7.9.1 General
The network-initiated liveness check procedure enables the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access to detect whether the UE is alive.
7.9.2 Network-initiated liveness check procedure initiation
If the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access has not received any cryptographically protected IKEv2 or IPsec message for the duration of the timeout period for liveness check selected according to the local policy, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall send an INFORMATIONAL request with no payloads IETF RFC 7296 [6].
7.9.3 Network-initiated liveness check procedure completion
The UE shall handle the INFORMATIONAL request with no payloads as per IETF RFC 7296 [6] and shall send an INFORMATIONAL response.
If an INFORMATIONAL response is received, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall consider the liveness check procedure as successfully completed.
7.9.4 Abnormal cases
If an INFORMATIONAL response is not received, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall deem the IKEv2 security association to have failed.
The N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall discard all states associated with the IKE SA and any child SAs that were negotiated using that IKE SA as specified in IETF RFC 7296 [6]. In addition, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall inform the AMF that the access stratum connection has been released.
7.10 IKE SA rekeying procedure
7.10.1 General
The N3IWF for untrusted non-3GPP access, the TNGF for trusted non-3GPP access and the UE may support the IKE SA rekeying procedure as specified in IETF RFC 7296 [6]. If the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access and the UE support the IKE SA rekeying procedure, the UE, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall proactively rekey the IKE SA. Upon rekeying of an IKE SA, the UE, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall maintain the old SA for the incoming data while establishing the new one. The old SA shall be deleted upon the completion of the establishment of the new one by both the UE, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access. The UE, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access are separately responsible for enforcing their time expiration policies to rekey the SA when needed. IETF RFC 7296 [6] describes how to avoid the simultaneous IPsec SA and IKE SA rekeying.
7.10.2 N3IWF-initiated and TNGF-initiated IKE SA rekeying procedure
7.10.2.1 N3IWF-initiated and TNGF-initiated IKE SA rekeying procedure initiation
The N3IWF for untrusted non-3GPP access, the TNGF for trusted non-3GPP access shall initiate the IKE SA rekeying procedure by sending a CREATE_CHILD_SA request message with a REKEY_SA Notify payload indicating an N3IWF’s SPI for untrusted non-3GPP access or an TNGF’s SPI for trusted non-3GPP access.
7.10.2.2 N3IWF-initiated and TNGF-initiated IKE SA rekeying procedure completion
Upon reception of the CREATE_CHILD_SA request message in the IKE SA with a REKEY_SA Notify payload indicating an N3IWF’s SPI for untrusted non-3GPP access or an TNGF’s SPI for trusted non-3GPP access, if the UE accepts the IKE SA rekeying request, the UE shall send a CREATE_CHILD_SA response message without an IKEv2 notify payload indicating an error, shall set the UE’s SPI to the SPI created by the CREATE_CHILD_SA request/response pair and shall set:
a) the N3IWF’s SPI for untrusted non-3GPP access to the N3IWF’s SPI; or
b) the TNGF’s SPI for trusted non-3GPP access to the TNGF’s SPI;
created by the CREATE_CHILD_SA request/response pair.
7.10.2.3 Abnormal cases
If the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access receive a CREATE_CHILD_SA response message with an IKEv2 notify payload indicating an error from the UE, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall delete the IKE SA and any associated child SAs as specified in clause 7.4.
If the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access do not receive any CREATE_CHILD_SA response message from the UE, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall discard all states associated with the IKE SA and any child SAs that were negotiated using that IKE SA. In addition, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall inform the AMF that the access stratum connection has been released.
7.10.3 UE-initiated IKE SA rekeying procedure
7.10.3.1 UE-initiated IKE SA rekeying procedure initiation
The UE shall initiate the IKE SA rekeying procedure by sending a CREATE_CHILD_SA request message with a REKEY_SA Notify payload indicating a UE’s SPI.
7.10.3.2 UE-initiated IKE SA rekeying procedure completion
Upon reception of the CREATE_CHILD_SA request message in the IKE SA with a REKEY_SA Notify payload indicating a UE’s SPI, if the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access accept the IKE SA rekeying request, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall send a CREATE_CHILD_SA response message without an IKEv2 notify payload indicating an error, shall set the N3IWF’s SPI for untrusted non-3GPP access and the TNGF’s SPI for trusted non-3GPP access to the SPI created by the CREATE_CHILD_SA request/response pair and shall set the UE’s SPI to the UE’s SPI created by the CREATE_CHILD_SA request/response pair.
7.10.3.3 Abnormal cases
If the UE receives a CREATE_CHILD_SA response message with an IKEv2 notify payload indicating an error from the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access, the UE shall delete the IKE SA and any associated child SAs as specified in clause 7.4.
If the UE does not receive any CREATE_CHILD_SA response message from the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access, the UE shall discard all states associated with the IKE SA and any child SAs that were negotiated using that IKE SA. In addition, the UE shall inform the upper layers that the access stratum connection has been released.
7.11 IPsec SA rekeying procedure
7.11.1 General
The N3IWF for untrusted non-3GPP access, the TNGF for trusted non-3GPP access and the UE may support the IPsec SA rekeying procedure as specified in IETF RFC 7296 [6]. If the N3IWF for untrusted non-3GPP access, the TNGF for trusted non-3GPP access and the UE support the IPsec SA rekying procedure, the UE, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall proactively rekey the IPsec SA. Upon rekeying of an IPsec SA, the UE, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall maintain the old IPsec for the incoming data while establishing the new one. The old IPsec shall be deleted upon the completion of the establishement of the new one by the UE, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access. The UE, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access are separately responsible for enforcing their time expiration policies to rekey the IPsec when needed. IETF RFC 7296 [6] describes how to avoid the simultaneous IPsec SA and IKE SA rekeying.
7.11.2 N3IWF-initiated and TNGF-initiated IPsec SA rekeying procedure
7.11.2.1 N3IWF-initiated and TNGF-initiated IPsec SA rekeying procedure initiation
The N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall initiate the IPsec SA rekeying procedure by sending a CREATE_CHILD_SA request message with a REKEY_SA Notify payload including a Protocol ID set to "3" and the N3IWF’s ESP SPI for untrusted non-3GPP access and the TNGF’s ESP SPI for trusted non-3GPP access for the IPsec SA.
7.11.2.2 N3IWF-initiated and TNGF-initiated IPsec SA rekeying procedure completion
Upon reception of the CREATE_CHILD_SA request message with a REKEY_SA Notify payload including a Protocol ID set to "3" and the N3IWF’s ESP SPI for untrusted non-3GPP access or the TNGF’s ESP SPI for trusted non-3GPP access for the IPsec SA, if the UE accepts the IPsec SA rekeying request, the UE shall send a CREATE_CHILD_SA response message without an IKEv2 notify payload indicating an error, shall set the UE’s ESP SPI to the ESP SPI created by the CREATE_CHILD_SA request/response pair and shall set;
a) the N3IWF’s ESP SPI for untrusted non-3GPP access; or
b) the TNGF’s ESP SPI for trsuted non-3GPP access;
to the N3IWF’s ESP SPI created by the CREATE_CHILD_SA request/response pair.
7.11.2.3 Abnormal cases
If the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access receive a CREATE_CHILD_SA response message with an IKEv2 notify payload indicating an error from the UE, the N3IWF shall delete the IPsec SA as specified in clause 7.7. Additionally, if the IPsec SA is the signalling IPsec SA, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall delete the IKE SA as specified in clause 7.4.
If the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access do not receive any CREATE_CHILD_SA response message from the UE, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall discard all states associated with the IKE SA and any child SAs that were negotiated using that IKE SA. In addition, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall inform the AMF that the access stratum connection has been released.
7.11.3 UE-initiated IPsec SA rekeying procedure
7.11.3.1 UE-initiated IPsec SA rekeying procedure initiation
The UE shall initiate the IPsec SA rekeying procedure by sending a CREATE_CHILD_SA request message with a REKEY_SA Notify payload including a Protocol ID set to "3" and the UE’s ESP SPI for the IPsec SA.
7.11.3.2 UE-initiated IPsec SA rekeying procedure completion
Upon reception of the CREATE_CHILD_SA request message with a REKEY_SA Notify payload including a Protocol ID set to "3" and the UE’s ESP SPI for the IPsec SA, if the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access accept the IPsec SA rekeying request, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall send a CREATE_CHILD_SA response message without an IKEv2 notify payload indicating an error, shall set:
a) the N3IWF’s ESP SPI for untrusted non-3GPP access; and
b) the TNGF’s ESP SPI for trusted non-3GPP access;
to the ESP SPI created by the CREATE_CHILD_SA request/response pair and shall set the UE’s ESP SPI to the UE’s ESP SPI created by the CREATE_CHILD_SA request/response pair.
7.11.3.3 Abnormal cases
If the UE receives a CREATE_CHILD_SA response message with an IKEv2 notify payload indicating an error from the N3IWF for untrusted non-3GPP access or the TNGF for trusted non-3GPP access, the UE shall delete the IPsec SA as specified in clause 7.7. Additionally, if the IPsec SA is the signalling IPsec SA, the UE shall delete the IKE SA as specified in clause 7.4.
If the UE does not receive any CREATE_CHILD_SA response message from the N3IWF for untrusted non-3GPP access or the TNGF for trusted non-3GPP access, the UE shall discard all states associated with the IKE SA and any child SAs that were negotiated using that IKE SA. In addition, the UE shall inform the upper layers that the access stratum connection has been released.