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:  19.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   5.3B…   6…   7…   7.2.5…   7.3…   7.3A…   7.4…   7.6…   7.9…   7.10…   8…   9…   9.3…   9.3.2…   9.3.2.2.3…   9.3.3… 
7.4 IKEv2 SA deletion procedure  7.4.1 General  7.4.2 IKE SA deletion procedure initiated by the N3IWF and the TNGF  7.4.2.1 IKE SA deletion initiation  7.4.2.2 IKE SA deletion accepted by the UE  7.4.2.3 Abnormal cases in the N3IWF and the TNGF  7.4.3 IKE SA deletion procedure initiated by the UE  7.4.3.1 IKE SA deletion initiation  7.4.3.2 IKE SA deletion accepted by the N3IWF and the TNGF  7.4.3.3 Abnormal cases in the UE  7.5 User plane IPsec SA creation procedure  7.5.1 General  7.5.2 Child SA creation procedure initiation  7.5.3 Child SA creation procedure accepted by the UE  7.5.4 Child SA creation procedure not accepted by the UE  7.5.5 Abnormal cases in the UE  7.5.6 Abnormal cases in the N3IWF and the TNGF 
...

 

7.4  IKEv2 SA deletion procedure  p. 65

7.4.1  General  p. 65

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:
  1. N1 NAS signalling connection release;
  2. N3IWF-initiated and TNGF-initiated IKE SA rekeying procedure failure;
  3. N3IWF-initiated and TNGF-intiated IKE SA rekeying procedure completion
  4. upon receipt of an INITIAL_CONTACT notification as specified in RFC 7296; and
  5. 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 IKE SA rekeying procedure failure;
  2. UE-initiated IKE SA rekeying procedure completion;
  3. upon receipt of an INITIAL_CONTACT notification as specified in RFC 7296; and
  4. upon detecting an error in a response packet as specified in RFC 7296.
Up

7.4.2  IKE SA deletion procedure initiated by the N3IWF and the TNGF  p. 65

7.4.2.1  IKE SA deletion initiation  p. 65

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 RFC 7296.
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:
  1. the N3IWF for untrusted non-3GPP access; and
  2. the TNGF for trusted non-3GPP access;
and the UE shall be deleted.
Up

7.4.2.2  IKE SA deletion accepted by the UE  p. 66

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

7.4.2.3  Abnormal cases in the N3IWF and the TNGF  p. 66

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

7.4.3  IKE SA deletion procedure initiated by the UE  p. 66

7.4.3.1  IKE SA deletion initiation  p. 66

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 RFC 7296.
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:
  1. the N3IWF for untrusted non-3GPP access; and
  2. the TNGF for trusted non-3GPP access;
and the UE shall be deleted.
Up

7.4.3.2  IKE SA deletion accepted by the N3IWF and the TNGF  p. 66

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

7.4.3.3  Abnormal cases in the UE  p. 67

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

7.5.1  General  p. 67

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:
  1. untrusted non-3GPP access, the N3IWF; or
  2. 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.
Up

7.5.2  Child SA creation procedure initiation  p. 67

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 RFC 7296.
The CREATE_CHILD_SA request message shall include:
  1. a UP_IP4_ADDRESS notify payload or a UP_IP6_ADDRESS notify payload;
  2. 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. an indication of whether the child SA is the default child SA. For a given PDU session ID, there shall be one and only one default child SA; and
    5. if trusted non-3GPP access, Additional QoS Information or if untrusted non-3GPP access, optionally Additional QoS Information; and
  3. the Traffic Selector (TS) set to match all packets as specified in RFC 7296.
The IKE CREATE_CHILD_SA request message also contains the SA payload for the requested child SA.
Up

7.5.3  Child SA creation procedure accepted by the UE  p. 67

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

7.5.4  Child SA creation procedure not accepted by the UE  p. 68

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 or PDU session modification 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 or PDU session modification over non-3GPP access.
  • If the UE is being treated as a UE with MPS priority (e.g., as identified in clause 7.3.2.1 or 7.3A.2.2) based on operator policy, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access may retry the Child SA creation without the Additional QoS Information.
Up

7.5.5  Abnormal cases in the UE  p. 68

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

7.5.6  Abnormal cases in the N3IWF and the TNGF  p. 68

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

Up   Top   ToC