Hello, 3GPP TS 24.302 states:
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 5996 [28]. If an INFORMATIONAL response is not received, the UE shall deem the IKEv2 security association to have failed. I.e. if the UE (client) follows the above, the UE (client) will always receive a cryptographically protected message within duration of (the timeout period for liveness check + one INFORMATIONAL transaction duration) - either an IPSec message, or an IKEv2 message, or an INFORMATIONAL response triggered by the sent INFORMATIONAL request. The above procedure intentionally does not depend on whether the UE (client) has any data to be sent or not. The reason is that when the UE (client) waits for incoming call setup request, the UE (client) still needs to be sure that ePDG is alive else incoming calls might be lost. This is true even if the UE (client) does not actually send any outgoing IP packets, just waiting for incoming IP packets carrying the incoming call setup request. > In other words - should UE in this situation perform a Liveness Check, > ignoring the ePDG provided interval? Liveness of ePDG is important regardless whether the UE (client) has data to be sent or not - see explanation above. Thus, why to perform an additional liveness check just because the UE (client) has data to be sent? > Or should it ignore the possibility to send data to a dead peer and perform > Liveness Checks only on the specified interval? The UE (client) should send the data immediately. The UE (client) should perform the liveness check regularly. Kind regards Ivo Sedlacek From: Valery Smyslov [mailto:sva...@gmail.com] Sent: Friday, February 26, 2016 2:27 PM To: Ivo Sedlacek; Tero Kivinen; Paul Wouters Cc: ipsec@ietf.org; frederic.fir...@etsi.org Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK Hi Ivo, thank you for providing more details. However, it is not clear from this description what UE should do if it has a data to be sent, but it received no protected data for some perion of time. Section 2.4. of RFC 7296 suggests that the IKEv2 implementation performs a Liveness Check in this case: If no cryptographically protected messages have been received on an IKE SA or any of its Child SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer. It is not clear how this text is supposed to align with TIMEOUT_PERIOD_FOR_LIVENESS_CHECK. In other words - should UE in this situation perform a Liveness Check, ignoring the ePDG provided interval? Or should it ignore the possibility to send data to a dead peer and perform Liveness Checks only on the specified interval? Regards, Valery Smyslov. ----- Original Message ----- From: Ivo Sedlacek<mailto:ivo.sedla...@ericsson.com> To: Tero Kivinen<mailto:kivi...@iki.fi> ; Paul Wouters<mailto:p...@nohats.ca> Cc: ipsec@ietf.org<mailto:ipsec@ietf.org> ; frederic.fir...@etsi.org<mailto:frederic.fir...@etsi.org> Sent: Thursday, February 25, 2016 6:58 PM Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK Hello, In case you are interested in detailed procedures of the 3GPP specification, I have copied them at the end of this mail. > > I am confused. Is this a notify of the server to the client, or a > > configuration item by the server instructing client behaviour? > > It is notify from the server to client. I.e. client sends empty > TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in the CFG_REQUEST and > server will send value in seconds inside its > TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in CFG_REPLY. I.e. the server asks client > to use following livenss timeout period. 3GPP spec expects that if the client (User Equipment) supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute, then the client (User Equipment) *enforces* the timer value indicated in the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute in CFG_REPLY sent by server (Evolved Packet Data Gateway). I.e. it is an intruction, not a suggestion. It is supposed to work as follows: first request --> IDi, [N(INITIAL_CONTACT)], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], [IDr], [CP(CFG_REQUEST (*TIMEOUT_PERIOD_FOR_LIVENESS_CHECK with empty value*) )], [N(IPCOMP_SUPPORTED)+], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, TSi, TSr, [V+][N+] first response <-- IDr, [CERT+], AUTH, EAP, [V+][N+] / --> EAP repeat 1..N times | \ <-- EAP last request --> AUTH last response <-- AUTH, [CP(CFG_REPLY(*TIMEOUT_PERIOD_FOR_LIVENESS_CHECK with a value selected by server*))], [N(IPCOMP_SUPPORTED)], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, TSi, TSr, [N(ADDITIONAL_TS_POSSIBLE)], [V+][N+] If the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK with a value selected by server is received as shown above, the client (user equipment) must perform the liveness check procedure with the timeout indicated by the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute. Detailed TS 24.302 client procedures related to the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute are: ------------- 7.2.2 Tunnel establishment 7.2.2.1 Tunnel establishment accepted by the network ..... The UE may support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in subclause 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. If the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in subclause 8.2.4.2 indicating the timeout period for the liveness check is included in the CFG_REPLY configuration payload or if the UE has a pre-configured timeout period, the UE shall perform the tunnel liveness checks as described in subclause 7.2.2A. NOTE: The timeout period for liveness check is pre-configured in the UE in implementation-specific way. ..... 7.2.2A Liveness check If the UE supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in subclause 8.2.4.2 and the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in subclause 8.2.4.2 was included in the CFG_REPLY configuration payload received in subclause 7.2.2 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 subclause 8.2.4.2 or the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in subclause 8.2.4.2 was not included in the CFG_REPLY configuration payload received in subclause 7.2.2 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 5996 [28]. If an INFORMATIONAL response is not received, the UE shall deem the IKEv2 security association to have failed. ------------- Detailed TS 24.302 server procedures related to the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute are: ------------- The ePDG shall proceed with IPsec tunnel setup completion and shall relay in the IKEv2 Configuration Payload (CFG_REPLY) of the final IKE_AUTH response message: ... - The ePDG may include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in subclause 8.2.4.2 indicating the timeout period for liveness check in the CFG_REPLY configuration 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. ... ------------- Kind regards Ivo Sedlacek ________________________________ _______________________________________________ IPsec mailing list IPsec@ietf.org<mailto:IPsec@ietf.org> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
