Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 24.502  Word version:  18.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   7…   7.3…   7.3A…   7.4…   7.6…   7.9…   7.10…   8…   9… 
7.6 IPsec SA modification procedure  7.6.1 General  7.6.2 N3IWF and TNGF procedure for IPsec child SA modification  7.6.3 UE procedure for IPsec child SA modification  7.7 IPSec SA deletion procedure  7.7.1 General  7.7.2 N3IWF-initated and TNGF-initiated child SA deletion procedure  7.7.3 UE-initiated child SA deletion procedure  7.7.4 Abnormal cases in the UE  7.7.5 Abnormal cases in the N3IWF and the TNGF  7.8 UE-initiated liveness check procedure  7.8.1 General  7.8.2 UE-initiated liveness check procedure initiation  7.8.3 UE-initiated liveness check procedure completion  7.8.4 Abnormal cases 
...

 

7.6  IPsec SA modification procedure  p. 54

7.6.1  General  p. 54

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  p. 54

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  p. 55

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

7.7  IPSec SA deletion procedure  p. 55

7.7.1  General  p. 55

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  p. 55

7.7.2.1  N3IWF-initiated and TNGF-initiated child SA deletion procedure initiation  p. 55

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  p. 56

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  p. 56

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 procedure  p. 56

7.7.3.1  UE-initiated child SA deletion procedure initiation  p. 56

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  p. 56

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  p. 56

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  p. 56

Apart from the cases specified in RFC 7296 and clause 7.7.3.3, no abnormal cases have been identified.

7.7.5  Abnormal cases in the N3IWF and the TNGF  p. 56

Apart from the cases specified in RFC 7296 and clause 7.7.2.3, no abnormal cases have been identified.

7.8  UE-initiated liveness check procedure  p. 57

7.8.1  General  p. 57

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  p. 57

If the UE supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in clause 8.2.4.2 of TS 24.302 and the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in clause 8.2.4.2 of TS 24.302 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 clause 8.2.4.2 of TS 24.302 or the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in clause 8.2.4.2 of TS 24.302 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.
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 completion  p. 57

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  p. 57

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