20 Tunnel management procedures UE to ePDG
36.523-13GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC)Part 1: Protocol conformance specificationRelease 17TSUser Equipment (UE) conformance specification
20.1 Void
20.2 Selection of ePDG and Tunnel establishment
20.2.1 Test Purpose (TP)
(1)
with { UE including ePDG configuration information }
ensure that {
when { The tunnel establishment procedure is initiated by the UE }
then { The UE transmits a DNS Query with QNAME set to FQDN of the ePDG }
}
(2)
with { UE has acquired an IP address }
ensure that {
when { UE has acquired the IP address of the ePDG }
then { UE transmits an IKE_SA_INIT Request message addressed to the ePDG to initiate security association establishment }
}
(3)
with { UE has transmitted an IKE_SA_INIT Request message addressed to the ePDG to initiate security association establishment }
ensure that {
when { UE receives an IKE_SA_INIT Response message }
then { UE transmits an IKE_AUTH Request message containing the configuration payload to request IP addresses for UE and for P-CSCF }
}
(4)
with { UE has transmitted an IKE_AUTH Request message containing the configuration payload }
ensure that {
when { UE receives an IKE_AUTH Response message including an EAP-Request/AKA Challenge }
then { UE transmits an IKE_AUTH Request message containing the correct EAP-Response/AKA-Challenge }
}
(5)
with { UE has transmitted an IKE_AUTH Request message containing an EAP-Response/AKA-Challenge }
ensure that {
when { UE receives an IKE_AUTH Response message including EAP-Success }
then { UE transmits an IKE_AUTH Request message with Authentication payload }
}
(6)
Void
20.2.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 23.003 clause 19.4.2.9.2, TS 24.302 clauses 4.4.3, 7.2.1 and 7.2.2.1, TS 23.402 clauses 4.5.4.2 and 8.2.2 and TS 24.229 clause R.2.2.1.
[Rel-13, TS 23.003, clause 19.4.2.9.2]
The ePDG Fully Qualified Domain Name (ePDG FQDN) contains an Operator Identifier that shall uniquely identify the PLMN where the ePDG is located. The ePDG FQDN is composed of seven labels. The last three labels shall be "pub.3gppnetwork.org". The third and fourth labels together shall uniquely identify the PLMN. The first two labels shall be "epdg.epc". The result of the ePDG FQDN will be:
"epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org"
[Rel-13, TS 24.302, clause 7.2.2.1]
Once the ePDG has been selected, the UE shall initiate the IPsec tunnel establishment procedure using the IKEv2 protocol as defined in IETF RFC 5996 and 3GPP TS 33.402.
The UE shall send an IKE_SA_INIT request message to the selected ePDG in order to setup an IKEv2 security association. Upon receipt of an IKE_SA_INIT response, the UE shall send an IKE_AUTH request message to the ePDG, including:
– The type of IP address (IPv4 address or IPv6 prefix or both) that needs to be configured in an IKEv2 CFG_REQUEST Configuration Payload. If the UE requests for both IPv4 address and IPv6 prefix, the UE shall send two configuration attributes in the CFG_REQUEST Configuration Payload: one for the IPv4 address and the other for the IPv6 prefix;
– The "IDr" payload, containing the APN in the Identification Data, for non-emergency session establishment. For emergency session establishment, the UE shall format the "IDr" payload according to subclause 7.2.5. The UE shall set the ID Type field of the "IDr" payload to ID_FQDN as defined in IETF RFC 5996 [28]. The UE indicates a request for the default APN by omitting the "IDr" payload, which is in accordance with IKEv2 protocol as defined in IETF RFC 5996 [28]; and
– The "IDi" payload containing the NAI.
…
After the successful authentication with the 3GPP AAA server, the UE receives from the ePDG an IKE_AUTH response message containing a single CFG_REPLY Configuration Payload including the assigned remote IP address information (IPv4 address or IPv6 prefix) as described in subclause 7.4.1.
…
During the IKEv2 authentication and security association establishment, following the UE’s initial IKE_AUTH request message to the ePDG, if the UE subsequently receives an IKE_AUTH response message from the ePDG containing the EAP-Request/AKA-Challenge, after verifying the received authentication parameters and successfully authenticating the ePDG as specified in 3GPP TS 33.402, the UE shall send a new IKE_AUTH request message to the ePDG including the EAP-Response/AKA-Challenge. In addition, the UE shall provide the requested mobile device identity if available, as specified in subclause 7.2.6.
[Rel-13, TS 23.402, clause 4.5.4.2]
When the UE attempts to construct an FQDN for selecting an ePDG in a certain PLMN-x (either a VPLMN or the HPLMN), then the UE shall construct one of the following FQDN formats:
– Operator Identifier FQDN: The UE constructs the FQDN by using the PLMN-x ID as the Operator Identifier.
– Tracking/Location Area Identity FQDN: The UE constructs the FQDN by using the identity of the Tracking Area/Location Area it is located in (i.e. based on PLMN-x ID and TAC/LAC). The Tracking/Location Area Identity FQDN is used to support location-specific ePDG selection within a PLMN.
The ePDG FQDN formats are specified in TS 23.003.
The UE selects one of the above FQDN formats as follows:
a) If the UE attempts to select an ePDG in the registered PLMN and the UE is configured to use for this PLMN the Tracking/Location Area Identity FQDN as defined in point 2) of clause 4.5.4.3; and
b) the UE knows the TAI/LAI of the area the UE it is located in (e.g. the TAI/LAI from the most recent Attach or TAU/LAU),
then the UE constructs a Tracking/Location Area Identity FQDN. Otherwise the UE constructs the Operator Identifier FQDN.
[Rel-13, TS 24.302, clause 4.4.3]
An ePDG Fully Qualified Domain Name (ePDG FQDN) is either provisioned by the home operator or constructed by UE in either the Operator Identifier FQDN format or the Tracking/Location Area Identity FQDN format as described in subclause 4.5.4.2 of 3GPP TS 23.402, and used as input to the DNS mechanism for ePDG selection.
The detailed format of this ePDG FQDN is specified in 3GPP TS 23.003.
[Rel-13, TS 24.302, clause 7.2.1]
The UE performs ePDG selection based on the ePDG configuration information configured by the home operator in the UE either via H-ANDSF or via USIM or via implementation specific means. The ePDG configuration information may consist of home ePDG identifier or ePDG selection information or both:
– when configured via H-ANDSF, the ePDG configuration information is provisioned in ePDG node under Home Network Preference as specified in 3GPP TS 24.312; and
– when configured via USIM, the ePDG configuration information is provisioned in EFePDGId and EFePDGSelection files as specified in 3GPP TS 31.102.
NOTE 1: Implementation specific means apply only if the configurations via H-ANDSF and USIM are not present.
The UE shall support the implementation of standard DNS mechanisms in order to retrieve the IP address(es) of the ePDG. The input to the DNS query is an ePDG FQDN as specified in subclause 4.4.3 and in 3GPP TS 23.003.
[Rel-13, TS 33.402, clause 8.2.2]
The tunnel end point in the network is the ePDG. As part of the tunnel establishment attempt the use of a certain APN is requested. When a new attempt for tunnel establishment is performed by the UE the UE shall use IKEv2 as specified in RFC 5996 [30]. The authentication of the UE in its role as IKEv2 initiator terminates in the 3GPP AAA Server. The UE shall send EAP messages over IKEv2 to the ePDG. The ePDG shall extract the EAP messages received from the UE over IKEv2, and send them to the 3GPP AAA Server. The UE shall use the Configuration Payload of IKEv2 to obtain the Remote IP address.
The EAP-AKA message parameters and procedures regarding authentication are omitted. Only decisions and processes relevant to the use of EAP-AKA within IKEv2 are explained.
The message flow for the full authentication is depicted in the Figure 8.2.2-1.
Figure 8.2.2-1: Tunnel full authentication and authorization
As the UE and ePDG generate nonces as input to derive the encryption and authentication keys in IKEv2, replay protection is provided. For this reason, there is no need for the 3GPP AAA Server to request the user identity again using the EAP-AKA specific methods (as specified in RFC 4187 [7]), because the 3GPP AAA Server is certain that no intermediate node has modified or changed the user identity.
1. The UE and the ePDG exchange the first pair of messages, known as IKE_SA_INIT, in which the ePDG and UE negotiate cryptographic algorithms, exchange nonces and perform a Diffie_Hellman exchange.
2. The UE sends the user identity (in the IDi payload) and the APN information (in the IDr payload) in this first message of the IKE_AUTH phase, and begins negotiation of child security associations. The UE omits the AUTH parameter in order to indicate to the ePDG that it wants to use EAP over IKEv2. The user identity shall be compliant with Network Access Identifier (NAI) format specified in TS 23.003 [8], containing the IMSI or the pseudonym, as defined for EAP-AKA in RFC 4187 [7]). The UE shall send the configuration payload (CFG_REQUEST) within the IKE_AUTH request message to obtain an IPv4 and/or IPV6 home IP Address and/or a Home Agent Address.
3. The ePDG sends the Authentication and Authorization Request message to the 3GPP AAA Server, containing the user identity and APN. The UE shall use the NAI as defined in accordance with clause 19.3 of 3GPP TS 23.003 [8], the 3GPP AAA server shall identify based on the realm part of the NAI that combined authentication and authorization is being performed for tunnel establishment with an ePDG which allows only EAP-AKA (and not an I-WLAN PDG as defined in TS 33.234 [9], which would allow also EAP-SIM). The different Diameter application IDs will help the 3GPP AAA Server distinguish among authentications for trusted access, as specified in clause 6 of the present document (which requires EAP-AKA’ authentication), and authentications for tunnel setup in EPS (which allows only EAP-AKA).
4. The 3GPP AAA Server shall fetch the authentication vectors from HSS/HLR (if these parameters are not available in the 3GPP AAA Server). The 3GPP AAA Server shall lookup the IMSI of the authenticated user based on the received user identity (root NAI or pseudonym) and include the EAP-AKA as requested authentication method in the request sent to the HSS. The HSS shall then generate authentication vectors with AMF separation bit = 0 and send them back to the 3GPP AAA server.
5. The 3GPP AAA Server initiates the authentication challenge. The user identity is not requested again.
6. The ePDG responds with its identity, a certificate, and sends the AUTH parameter to protect the previous message it sent to the UE (in the IKE_SA_INIT exchange). The EAP message received from the 3GPP AAA Server (EAP-Request/AKA-Challenge) is included in order to start the EAP procedure over IKEv2.
7. The UE checks the authentication parameters and responds to the authentication challenge. The IKE_AUTH request message includes the EAP message (EAP-Response/AKA-Challenge) containing UE’s response to the authentication challenge.
8. The ePDG forwards the EAP-Response/AKA-Challenge message to the 3GPP AAA Server.
8.a The AAA checks, if the authentication response is correct.
8.b-e If dynamic IP mobility selection is executed embedded to the authentication and authorization, the selected mobility mode is sent to the user in an AKA-Notification request, over Diameter A&A answer and IKE_AUTH message. The UE responds to this over IKEv2 and the ePDG forwards the response to the 3GPP AAA Server.
8A. The 3GPP AAA Server shall initiate the Subscriber Profile Retrieval and 3GPP AAA Server registration to the HSS. The 3GPP AAA Server checks in user’s subscription if he/she is authorized for non-3GPP access.
9. When all checks are successful, the 3GPP AAA Server sends the final Authentication and Authorization Answer (with a result code indicating success) including the relevant service authorization information, an EAP success and the key material to the ePDG. This key material shall consist of the MSK generated during the authentication process. When the SWm and SWd interfaces between ePDG and 3GPP AAA Server are implemented using Diameter, the MSK shall be encapsulated in the EAP-Master-Session-Key-AVP, as defined in RFC 4072 [10].
10. The MSK shall be used by the ePDG to generate the AUTH parameters in order to authenticate the IKE_SA_INIT phase messages, as specified for IKEv2 in RFC 5996 [30]. These two first messages had not been authenticated before as there was no key material available yet. According to RFC 5996 [30], the shared secret generated in an EAP exchange (the MSK), when used over IKEv2, shall be used to generated the AUTH parameters.
11. The EAP Success/Failure message is forwarded to the UE over IKEv2.
12. The UE shall take its own copy of the MSK as input to generate the AUTH parameter to authenticate the first IKE_SA_INIT message. The AUTH parameter is sent to the ePDG.
13. The ePDG checks the correctness of the AUTH received from the UE. At this point the UE is authenticated. In case S2b is used, PMIP signalling between ePDG and PDN GW can now start, as specified in TS 23.402 [5]. The ePDG continues with the next step in the procedure described here only after successful completion of the PMIP binding update procedure.
14. The ePDG calculates the AUTH parameter which authenticates the second IKE_SA_INIT message. The ePDG shall send the assigned Remote IP address in the configuration payload (CFG_REPLY).
15 The AUTH parameter is sent to the UE together with the configuration payload, security associations and the rest of the IKEv2 parameters and the IKEv2 negotiation terminates.
[Rel-13, TS 24.229, clause R.2.2.1]
Prior to communication with the IM CN subsystem:
…
a) the UE establishes an IP-CAN bearer for SIP signalling as follows:
…
b) the UE shall acquire a P-CSCF address(es).
…
The methods for P-CSCF discovery are:
…
IV. Obtain P-CSCF address(es) using signalling for access to the EPC via WLAN.
If the UE attaches to the EPC via S2b using untrusted WLAN IP access, the UE shall request P-CSCF IPv4 address(es), P-CSCF IPv6 address(es) or both using the P_CSCF_IP4_ADDRESS attribute, the P_CSCF_IP6_ADDRESS attribute or both in the CFG_REQUEST configuration payload as described in 3GPP TS 24.302 [8U]. The network can provide the UE with the P-CSCF IPv4 address(es), P-CSCF IPv6 address(es) or both using the P_CSCF_IP4_ADDRESS attribute, the P_CSCF_IP6_ADDRESS attribute or both in the CFG_REPLY configuration payload as described in 3GPP TS 24.302 [8U]. If the UE receives multiple P-CSCF IPv4 or IPv6 addresses, the UE shall assume that the list is ordered top-down with the first P-CSCF address within the CFG_REPLY configuration payload as the P-CSCF address having the highest preference and the last P-CSCF address within the CFG_REPLY configuration payload as the P-CSCF address having the lowest preference.
20.2.3 Test description
20.2.3.1 Pre-test conditions
System Simulator:
– WLAN Cell 27 according to Table 4.4.8-1 in [18].
UE:
– None
Preamble:
– The UE is in state Switched OFF (state 1) according to [18].
20.2.3.2 Test procedure sequence
Table 20.2.3.2-1: Main behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
The UE is switched on. |
– |
– |
– |
– |
|
2 |
UE associates with the WLAN AP and obtains the local IP address. |
– |
– |
– |
– |
|
– |
EXCEPTION: In parallel to the event described in steps 3 and 4 below the UE may transmit other DNS queries |
– |
– |
– |
– |
|
3 |
Check: Does the UE transmit a DNS Query message with QNAME set to FQDN of the ePDG? |
–> |
DNS Query |
1 |
P |
|
4 |
The SS transmits a DNS Response message with the IP address of the ePDG. |
<– |
DNS Response |
– |
– |
|
5 |
Check: Does the UE transmit an IKE_SA_INIT message to the ePDG? |
–> |
IKE_SA_INIT Request |
2 |
P |
|
6 |
The SS transmits an IKE_SA_INIT message |
<– |
IKE_SA_INIT Response |
– |
– |
|
7 |
Check: Does the UE transmit an IKE_AUTH Request message including a Configuration payload? |
–> |
IKE_AUTH Request |
3 |
P |
|
8 |
The SS transmits an IKE_AUTH Response message including an EAP-Request/AKA-Challenge. |
<– |
IKE_AUTH Response |
– |
– |
|
9 |
Check: Does the UE transmit an IKE_AUTH Request message including the EAP-Response/AKA-Challenge? |
–> |
IKE_AUTH Request |
4 |
P |
|
10 |
The SS transmits an IKE_AUTH Response message including EAP-Success. |
<– |
IKE_AUTH Response |
– |
– |
|
11 |
Check: Does the UE transmit an IKE_AUTH Request message with Authentication payload? |
–> |
IKE_AUTH Request |
5 |
P |
|
12 |
The SS transmits an IKE_AUTH Response message with Authentication and Configuration payloads. |
<– |
IKE_AUTH Response |
– |
– |
|
13-21 |
The UE performs the IMS registration procedure according TS 34.229-1 [43] subclause C.2c (steps 2-9). |
– |
– |
– |
– |
20.2.3.3 Specific message contents
Table 20.2.3.3-1: Message DNS Query (step 3, Table 20.2.3.2-1)
|
Derivation path: IETF RFC 1035 [56] |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
QR= |
‘0’ |
Query |
|
|
OPCODE= |
‘0000’ |
QUERY |
|
|
QNAME= |
Operator provisioned FQDN of the ePDG. |
pc_ePDG_FQDN_Provisioned |
|
|
Operator Identifier FQDN format shall be "epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org" |
pc_ePDG_FQDN_constructed |
||
|
QTYPE= |
A |
query for the IPv4 address |
IPv4 |
|
AAAA |
query for the IPv6 address |
IPv6 |
|
|
QCLASS= |
IN |
||
|
Condition |
Explanation |
|
IPv4 |
DNS query for IPv4 address |
|
IPv6 |
DNS query for IPv6 address |
Table 20.2.3.3-2: Message DNS Response (step 4, Table 20.2.3.2-1)
|
Derivation path: IETF RFC 1035 [56] |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
QR= |
‘1’ |
Response |
|
|
OPCODE= |
‘0000’ |
QUERY |
|
|
QNAME= |
Same as received in DNS Query |
||
|
QTYPE= |
A |
||
|
QCLASS= |
IN |
||
|
RR { |
|||
|
NAME |
Same as received in DNS Query |
||
|
TYPE |
Same as received in DNS Query |
A for IPv4 AAAA for IPv6 |
|
|
CLASS |
IN |
||
|
RDATA |
IP address of ePDG |
||
|
} |
|||
Table 20.2.3.3-2A: IKE_AUTH request (step 7, Table 20.2.3.2-1)
|
Derivation path: 36.508 table 4.7G-3 |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
IKE Header |
|||
|
Next Payload |
‘00101111’B |
CP |
|
|
Exchange Type |
‘00100011’B |
IKE_AUTH |
|
|
Configuration Payload |
|||
|
Next Payload |
‘00000000’B |
No Next Payload if CP is the last payload |
|
|
CFG Type |
‘00000001’B |
CFG_REQUEST |
|
|
Attribute Type |
‘00000001’B |
INTERNAL_IP4_ADDRESS |
IPv4 |
|
IPv4 Address |
Not checked |
IPv4 |
|
|
Attribute Type |
‘00001000’B |
INTERNAL_IP6_ADDRESS |
IPv6 |
|
IPv6 Address |
Not checked |
IPv6 |
|
|
Attribute Type |
‘00010100’B |
P_CSCF_IP4_ADDRESS |
IPv4 |
|
IPv4 Address |
Not checked |
IPv4 |
|
|
Attribute Type |
‘00010101’B |
P_CSCF_IP6_ADDRESS |
IPv6 |
|
IPv6 Address |
Not checked |
IPv6 |
|
|
NOTE 1: The order of Payloads/fields is not checked, unless explicitly specified. Additional Payloads/fields are ignored. |
|||
|
Condition |
Explanation |
|
IPv4 |
If the UE requests an IPv4 address |
|
IPv6 |
If the UE requests an IPv6 address |
|
NOTE: At least one of IPv4 and IPv6 shall be true. |
|
Table 20.2.3.3-2B: IKE_AUTH request (step 9, Table 20.2.3.2-1)
|
Derivation path: 36.508 table 4.7G-3 |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
IKE Header |
|||
|
Next Payload |
‘00110000’B |
EAP |
|
|
Exchange Type |
‘00100011’B |
IKE_AUTH |
|
|
Extensible Authentication Payload |
|||
|
Next Payload |
‘00000000’B |
No Next Payload if EAP is the last payload |
|
|
Code |
‘00000010’B |
Response |
|
|
Identifier |
Not checked |
||
|
Type |
Not checked |
||
|
Type_Data |
Not checked |
||
|
NOTE 1: The order of Payloads/fields is not checked, unless explicitly specified. Additional Payloads/fields are ignored. |
|||
Table 20.2.3.3-3: IKE_AUTH request (step 11, Table 20.2.3.2-1)
|
Derivation path: 36.508 table 4.7G-3 |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
IKE Header |
|||
|
Next Payload |
‘00101111’B |
AUTH |
|
|
Exchange Type |
‘00100011’B |
IKE_AUTH |
|
|
Authentication Payload |
|||
|
Next Payload |
‘00000000’B |
No Next Payload if AUTH is the last payload |
|
|
Authentication Method |
Not checked |
||
|
Authentication Data |
Not checked |
||
|
NOTE 1: The order of Payloads/fields is not checked, unless explicitly specified. Additional Payloads/fields are ignored. |
|||
Table 20.2.3.3-4: IKE_AUTH response (step 12, Table 20.2.3.2-1)
|
Derivation path: 36.508 table 4.7G-4 |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
IKE Header |
|||
|
Next Payload |
‘00101111’B |
CP |
|
|
Exchange Type |
‘00100011’B |
IKE_AUTH |
|
|
Configuration Payload |
|||
|
Next Payload |
Set by the SS |
||
|
CFG Type |
‘00000010’B |
CFG_REPLY |
|
|
Attribute Type |
‘00000001’B |
INTERNAL_IP4_ADDRESS |
IPv4 |
|
IPv4 Address |
Set by the SS |
IPv4 |
|
|
Attribute Type |
‘00001000’B |
INTERNAL_IP6_ADDRESS |
IPv6 |
|
IPv6 Address |
Set by the SS |
IPv6 |
|
|
Attribute Type |
‘00010100’B |
P_CSCF_IP4_ADDRESS |
|
|
IPv4 Address |
Set by the SS |
||
|
Attribute Type |
‘00010101’B |
P_CSCF_IP6_ADDRESS |
|
|
IPv6 Address |
Set by the SS |
||
|
Condition |
Explanation |
|
IPv4 |
If the UE requested an IPv4 address |
|
IPv6 |
If the UE requested an IPv6 address |
20.3 UE initiated disconnection
20.3.1 Test Purpose (TP)
(1)
with { UE has an established tunnel }
ensure that {
when { UE initiate disconnection }
then { UE transmits an INFORMATIONAL Request message containing the delete payload }
}
20.3.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 24.302 clause 7.2.4.1.
[Rel-13, TS 24.302, clause 7.2.4.1]
The UE shall use the procedures defined in the IKEv2 protocol (see IETF RFC 5996 [28]) to disconnect an IPsec tunnel to the ePDG. The UE shall close the incoming security associations associated with the tunnel and instruct the ePDG to do the same by sending the INFORMATIONAL request message including a "DELETE" payload. The DELETE payload shall contain either:
i) Protocol ID set to "1" and no subsequent Security Parameters Indexes (SPIs) in the payload. This indicates closing of IKE security association, and implies the deletion of all IPsec ESP security associations that were negotiated within the IKE security association; or
ii) Protocol ID set to "3" for ESP. The Security Parameters Indexes included in the payload shall correspond to the particular incoming ESP security associations at the UE for the given tunnel in question.
20.3.3 Test description
20.3.3.1 Pre-test conditions
System Simulator:
– WLAN Cell 27 according to Table 4.4.8-1 in [18].
UE:
– None
Preamble:
– The UE has an established tunnel according to table 4.5A.23.3-1 in [18].
20.3.3.2 Test procedure sequence
Table 20.3.3.2-1: Main behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
Make UE initiate disconnection. |
– |
– |
– |
– |
|
– |
EXCEPTION: Table 20.3.3.2-2 describes optional behaviour that depends on the UE implementation |
– |
– |
||
|
2 |
Check: Does the UE transmit an INFORMATIONAL Request message including a Delete payload? |
–> |
INFORMATIONAL Request |
1 |
P |
|
3 |
The SS transmits an INFORMATIONAL Response message. |
<– |
INFORMATIONAL Response |
– |
– |
Table 20.3.3.2-2: Optional behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
The SS starts Timer_1 = 2 seconds |
– |
– |
– |
– |
|
– |
EXCEPTION: Steps 2a1 – 2b1 describe behaviour that depends on the UE implementation |
– |
– |
– |
– |
|
2a1 |
IMS de-registration is performed using the generic procedure defined in 34.229-1 [40] Annex C.30. Note: The SS cancels the Timer_1 |
– |
– |
– |
– |
|
2b1 |
The SS waits for Timer_1 expiry |
– |
– |
– |
– |
20.3.3.3 Specific message contents
Table 20.3.3.3-1: INFORMATIONAL request (step 2, Table 20.3.3.2-1)
|
Derivation path: IETF RFC 5996 [57] |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
IKE Header |
|||
|
Next Payload |
‘00101010’B |
D |
|
|
Exchange Type |
‘00100011’B |
INFORMATIONAL |
|
|
Delete Payload |
|||
|
Next Payload |
‘00000000’B |
No Next Payload if D is the last payload |
|
|
Protocol ID |
‘00000001’B |
For IKE SA |
|
|
NOTE 1: The order of Payloads/fields is not checked, unless explicitly specified. Additional Payloads/fields are ignored. |
|||
Table 20.3.3.3-2: INFORMATIONAL response (step 3, Table 20.3.3.2-1)
|
Derivation path: IETF RFC 5996 [57] |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
IKE Header |
|||
|
Next Payload |
‘00101010’B |
D |
|
|
Exchange Type |
‘00100011’B |
INFORMATIONAL |
|
|
Delete Payload |
|||
|
Next Payload |
‘00000000’B |
No Next Payload |
|
|
Protocol ID |
‘00000001’B |
For IKE SA |
|
20.4 ePDG initiated disconnection
20.4.1 Test Purpose (TP)
(1)
with { UE has an established tunnel }
ensure that {
when { UE receives an INFORMATIONAL Request message including a delete payload }
then { UE transmits an INFORMATIONAL Response message }
}
20.4.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 24.302 clause 7.2.4.2.
[Rel-13, TS 24.302, clause 7.2.4.2]
On receipt of the INFORMATIONAL request message including "DELETE" payload, indicating that the ePDG is attempting tunnel disconnection, the UE shall:
i) Close all security associations identified within the DELETE payload (these security associations correspond to outgoing security associations from the UE perspective). If no security associations were present in the DELETE payload, and the protocol ID was set to "1", the UE shall close the IKE security association, and all IPsec ESP security associations that were negotiated within it towards the ePDG; and
ii) The UE shall delete the incoming security associations corresponding to the outgoing security associations identified in the "DELETE" payload.
The UE shall send an INFORMATIONAL response message. If the INFORMATIONAL request message contained a list of security associations, the INFORMATIONAL response message shall contain a list of security associations deleted in step (ii) above.
If the UE is unable to comply with the INFORMATIONAL request message, the UE shall send INFORMATION response message with either:
i) A NOTIFY payload of type "INVALID_SPI", for the case that it could not identify one or more of the Security Parameters Indexes in the message from the ePDG; or
ii) A more general NOTIFY payload type. This payload type is implementation dependent.
If the INFORMATIONAL request message including the DELETE payload contains the REACTIVATION_REQUESTED_CAUSE Notify payload, the UE shall re-establish the IPsec Tunnel for the corresponding PDN connection after its release. The coding of the P-CSCF_RESELECTION_SUPPORT Notify payload is described in subclause 8.2.9.6.
NOTE: For an IMS PDN connection, the re-establishment of the IPSec tunnel is part of the "Re-establishment of the IP-CAN used for SIP signalling procedure" specified in 3GPP TS 24 229 [67] subclause R.2.2.1B.
20.4.3 Test description
20.4.3.1 Pre-test conditions
System Simulator:
– WLAN Cell 27 according to Table 4.4.8-1 in [18].
UE:
– None
Preamble:
– The UE has an established tunnel according to table 4.5A.23.3-1 in [18].
20.4.3.2 Test procedure sequence
Table 20.4.3.2-1: Main behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
The SS transmits an INFORMATIONAL Request message including a Delete payload. |
<– |
INFORMATIONAL Request |
– |
– |
|
2 |
Check: Does the UE transmit an INFORMATIONAL Response message? |
–> |
INFORMATIONAL Response |
1 |
P |
20.4.3.3 Specific message contents
Table 20.4.3.3-1: INFORMATIONAL request (step 1, Table 20.4.3.2-1)
|
Derivation path: IETF RFC 5996 [57] |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
IKE Header |
|||
|
Next Payload |
‘00101010’B |
D |
|
|
Exchange Type |
‘00100011’B |
INFORMATIONAL |
|
|
Delete Payload |
|||
|
Next Payload |
‘00000000’B |
No Next Payload |
|
|
Protocol ID |
‘00000001’B |
For IKE SA |
|
Table 20.4.3.3-2: INFORMATIONAL response (step 2, Table 20.4.3.2-1)
|
Derivation path: IETF RFC 5996 [57] |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
IKE Header |
|||
|
Next Payload |
Not checked |
||
|
Exchange Type |
‘00100011’B |
INFORMATIONAL |
|
|
NOTE 1: The order of Payloads/fields is not checked, unless explicitly specified. Additional Payloads/fields are ignored. |
|||