Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 24.502  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   7…   7.3…   7.3A…   7.4…   7.6…   7.9…   7A…   8…   9…

 

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 RFC 7296 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:
  1. if the content of the 5G_QOS_INFO Notify payload is accepted by the UE, the UE shall:
    1. 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
    2. update locally the IPsec child SA according to the content of the INFORMATIONAL request message; or
  2. if the content of the 5G_QOS_INFO Notify payload is not accepted by the UE, the UE shall:
    1. send the reason for rejecting the IPsec SA modification in the content of an INFORMATIONAL response message; and
    2. not update locally the IPsec child SA according to the content of the INFORMATIONAL request message.
If the UE fails to reserve QoS resources over non-3GPP access for the QoS flows associated with the child SA 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.
Up

7.7  IPSec SA deletion procedureWord‑p. 49

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:
  1. upon PDU session release;
  2. N3IWF-initiated and TNGF-intiated IPsec SA rekeying procedure failure;
  3. N3IWF-initiated and TNGF-intiated IPsec SA rekeying procedure completion; and
  4. upon detecting an error in a response packet as specified in RFC 7296.
The UE initiates this procedure in the following cases:
  1. UE-initiated IPsec SA rekeying procedure failure;
  2. UE-initiated IPsec SA rekeying procedure completion; and
  3. upon detecting an error in a response packet as specified in RFC 7296.
Up

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 RFC 7296. The Delete payload shall include:
  1. the Protocol ID set to "3" for ESP; and
  2. 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.
Up

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 RFC 7296.
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.
Up

7.7.3  UE-initiated child SA deletion procedureWord‑p. 50

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 RFC 7296], to the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access. The Delete payload shall include:
  1. the Protocol ID set to "3" for ESP; and
  2. 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 RFC 7296.
Any IKEv2 Notify payload indicating an error shall not be included in the INFORMATIONAL response message.
Up

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 RFC 7296 and subclause 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 RFC 7296 and subclause 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 TS 24.302 subclause 8.2.4.2 and the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in TS 24.302 subclause 8.2.4.2 was included in the CFG_REPLY configuration payload within the IKE_AUTH response message received in subclause 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 TS 24.302 subclause 8.2.4.2 or the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in TS 24.302 subclause 8.2.4.2 was not included in the CFG_REPLY configuration payload within the IKE_AUTH response message received in subclause 7.3, then the UE shall use the pre-configured value of the timeout period for liveness check.
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 RFC 7296.
Up

7.8.3  UE-initiated liveness check procedure completionWord‑p. 51
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 RFC 7296 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 RFC 7296]. In addition, the UE shall inform the upper layers that the access stratum connection has been released.

Up   Top   ToC