Subject: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK

From: Tero Kivinen <[email-masked]>
Date: Thu, 25 Feb 2016 16:09:54 +0200

I as an IANA expert got request from 3gpp to allocate new
configuration attribute called TIMEOUT_PERIOD_FOR_LIVENESS_CHECK for
IKEv2. This is used to set the timeout after which the UE will do
liveness check with other end if no cryptographically protected IKEv2
or IPSec messages are not received.

I.e. it is mostly same procedure as RFC7296 but in this case the the
parameter is not locally configured, but sent by the server end.

I can see some merit for this as this allows the server to limit the
number of liveness checks by sending larger number, for example 600
seconds. Some implementations use really short liveness check timeouts
and send the liveness checks ever n seconds when connection is silent.
Some implementaions simply do one liveness check after the connection
goes silent, but after that assumes that connection is ok as long as
there is no packets going out, and only redo the liveness check after
they have sent something out and not received anything back.

This is more in align with first use, i.e. the text asks to send
liveness check this often even if the connection is completely silent.
The IKEv2 text says we do liveness checks to avoid black holes, and
there cannot be black holes for packets if we do not send packets,
thus we are not supposed to send liveness checks if both ends are
silent.

I am thinking of saying "go ahead" for IANA for this allocation even
when this do change the IKEv2 bit, as I think there are
implementations using same interpretation out there, and I think this
configuration attribute is mostly harmless. If we would have done it
here in the IPsecME WG, I think we would have used notifications
instead of configuration payloads, as this attribute do affect the
whole IKE SA and is not configuration attribute related to IPsec SA.

So unless people object I will say "go ahead" in few days.

Ps, I still think it would be better for 3gpp to run their additions
to IKEv2 through the IPsecME WG first to get some feedback for them
before adding them to their drafts (i.e. send email to the list and
ask for comments, no need to write internet drafts about proposals,
but just explain why and what they plan to do). I at least would be
more than happy to provide them feedback earlier, as I think this IANA
allocation phase is too late phase to do such things.

Original allocation request:

===

Contact Name:
Frederic Firmin

Contact Email:
[email-masked]

Type of Assignment: New item in the "IKEv2 Configuration Payload
Attribute Types" of the "Internet Key Exchange Version 2 (IKEv2)
Parameters" as shown at
http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-21
and as specified in IETF RFC 4306 and updated by IETF RFC 5996 and
IETF RFC 7296.

Registry: The "IKEv2 Configuration Payload Attribute Types" of the
"Internet Key Exchange Version 2 (IKEv2) Parameters" as shown at
http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-21
and as specified in IETF RFC 4306 and updated by IETF RFC 5996 and
IETF RFC 7296.

Description:
This IKEv2 attribute is used to provide configuration for performing the liveness checks.

Additional Info: ETF RFC 4306 defines the registry for the "IKEv2
Configuration Payload Attribute Types". IETF RFC 7296 and IETF RFC
5996 refer to IETF RFC 4306 for the definition of the registry. The
following attribute is requested to be registered: - value: (number to
be assigned by IANA) - attribute type:
TIMEOUT_PERIOD_FOR_LIVENESS_CHECK - multi-valued: no - length: 4
octets - reference: 24.302 13.4.0
http://www.3gpp.org/ftp/Specs/html-info/24302.htm 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Feb 2016 09:25:32 -0500 (EST)

> parameter is not locally configured, but sent by the server end.

I am confused. Is this a notify of the server to the client, or a
configuration item by the server instructing client behaviour?

> seconds.

So this seems like it is a configuration dictated by the server for
the client to use. What if the client disagrees? Does it ignore this
and use its own local policy?

> Some implementations use really short liveness check timeouts

So with this option, is the server now allowed to not answer a liveness
probe and should the client not close the connection if it receives no
answer?

> liveness check this often even if the connection is completely silent.

That's something that could go into an 7296 update as it is a useful
policy change in general (and likely already implemented by some. We
do this already as well)

> thus we are not supposed to send liveness checks if both ends are

Sure, that text could use an update.

> configuration attribute is mostly harmless.

The text below cities still does not make it clear to me if this is
a notification or an instruction.

> If we would have done it

But a notify is something that is informative, not instructive. So now
I am all confused again.

> So unless people object I will say "go ahead" in few days.

I would _really_ prefer a 2 page draft that states the problem and
the solution, so that it becomes clear if these are local policy
suggestions or actual configuration requirements the client has to
accept or reject.

> allocation phase is too late phase to do such things.

Yes. The IKEv2 registries are filling up with non-ikev2 entries. It
would really make sense to run this through the working group. I'll
bring this issue up in the TEG/TLC next week.

Paul

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 25 Feb 2016 17:51:25 +0300

Hi,

> So unless people object I will say "go ahead" in few days.

I don't strongly object, however I have a concern:
how server can enforce the timeout period it sent to the client?
The client can ignore it and do liveness check more often
(for a good reason, if it has some data to send and has
no reply from server) or less often. It seems that this 
notification could be ignored by the client completely and the server
cannot do anything about this (otherwise than tear down the 
connection with "bad boy", but is it an intention?).
Or is this notification just a hint, not an enforcement?

> allocation phase is too late phase to do such things.

Yes.

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 25 Feb 2016 16:52:27 +0200

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

> and use its own local policy?

This is 3gpp, and what ePDG says is the law. No-one dares to disagree
:-)

I.e. their specification does not say anything about what happens if
client disagrees. It do say that if it does not support this, then it
will use whatever preconfigured value it has.

On the other hand if client does not follow this request, there is
nothing server can do. I.e. this only specifies how client sends those
messages after timeout, it does not say that server should act on
those messages. I.e., I do not think server can do anything based on
the fact that it got them too often, or did not get them often
enough... 

> probe and should the client not close the connection if it receives no

No. Server will respond to them as normally as this is normal
mandatory behavior from IKEv2, and yes client will close the
connection if server does not respond just like with normal IKEv2
liveness check. 

> policy change in general (and likely already implemented by some. We

I think that is bad policy and I think it can be silently be allowed,
but I do not really think we should encourage it.

If connection is completely silent, i.e. no traffic flowing at all in
either direction, there is no point of sending any liveness checks
over it. In that case those liveness checks are just make dead
packets.

If your VPN is silent and no messages are going through (you are
sleeping), and there is 30 minute network failure during the night,
the make dead packets will kill your VPN and in the morning you need
to retype your password even when the connection is working at that
point.

If you do not send make dead packets during the idle period, in the
morning when you come to the keyboard and hit first time any key, that
will send the packet to the other end and if other end is still up and
running, VPN will continue stay up. If the other end has rebooted, it
will reply with ICMP or IKE invalid SPI notify, which will trigger
liveness check, and then the connection will be deleted quite soon,
and new one connection is formed. 

> a notification or an instruction.

My understanding is that it is notification, i.e. there is no rules in
the specification saying that server end should expect those liveness
checks, and do something if it gets them or does not get them.

> But a notify is something that is informative, not instructive. So now

That is my inderstanding what this is. You can go and download the
http://www.3gpp.org/ftp/Specs/html-info/24302.htm and check yourself. 

> suggestions or actual configuration requirements the client has to

If we could even get few paragraph explanation that would be really
good, thats why I said it would be nice if 3gpp people would run their
additions through this list before writing it in their draft.

Now I have to check that 116 page document and find out what it is
supposed to do :-)

> bring this issue up in the TEG/TLC next week.

What is TEG/TLC?

-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 25 Feb 2016 16:55:09 +0200

> Or is this notification just a hint, not an enforcement?

That is my understanding with this, and this is why I consider this
"mostly harmless".

Of course it would be easier to get information directly from people
who are proposing this, and not just my interpretation of the issue. 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Feb 2016 10:06:29 -0500 (EST)

> CFG_REPLY. I.e. the server asks client to use following livenss

Ok, then it should use NOTIFY and not CP.

> but I do not really think we should encourage it.

[ little off-topic. your arguments make sense and I will look at our
   implementation again :) ]

> Now I have to check that 116 page document and find out what it is

So this is a real problem. If we (implementors) want to implement these
IKEv2 extensions, we need to have clear proper RFC's. I do not want to
find 116 pages on third party websites (that may or may not be behind
a registration or pay wall)

>> bring this issue up in the TEG/TLC next week.

https://www.icann.org/resources/pages/tlg-73-2012-02-25-en

It is a liaison group for the ICANN board consisting of various groups
including ETSI, ITU, W3C and IETF. While this does not relate directly
to ICANN (names/dns), it does have the right people there to talk about
this kind of issue.

Paul

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 25 Feb 2016 15:21:06 +0000

Hello,

> 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+]

Kind regards

Ivo Sedlacek

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 25 Feb 2016 15:58:34 +0000

Hello,

In case you are interested in detailed procedures of the 3GPP specification, I have copied them at the end of this mail.

   first request       --> IDi,

                           [N(INITIAL_CONTACT)],

                           [IDr],

                           [N(IPCOMP_SUPPORTED)+],

                           [N(USE_TRANSPORT_MODE)],

                           SA, TSi, TSr,

                           [V+][N+]

                           EAP,

                           [V+][N+]

                     / --> EAP

   repeat 1..N times |

                     \ <-- EAP

   last request        --> AUTH

   last response       <-- AUTH,

                           [N(IPCOMP_SUPPORTED)],

                           [N(USE_TRANSPORT_MODE)],

                           SA, TSi, TSr,

                           [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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 26 Feb 2016 13:11:32 +0200

> Ok, then it should use NOTIFY and not CP.

That is my understanding too, but I do not really think this issue is
big enough to require them to change their document, i.e., not to
approve their IANA allocation request. 

> a registration or pay wall)

Most of that 116 pages is not related to the IKEv2 extensions, there
is perhaps few tens of pages of IKEv2 related things in there. The
documents can be downloaded from their web page, and as they do cover
the 3gpp Evolved Packet Core (EPC) issues, I do not think they need to
be RFCs. This is the reason why the IANA registries for IKEv2 are not
RFC required...

Anyways making suggestions like in the beginning of this email (i.e.
use notify instead of configuration payload) is something that would
be good to do before people define extensions to the IKEv2, and thats
why I do encourage people to at least tell what they are doing, and
why and how in the ipsec list while making the protocol, so we can
give them hints and feedback how to do it properly. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 26 Feb 2016 13:24:13 +0200

Ivo Sedlacek writes:
> 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).
> 

Yes, but there is nothing there to say what the server will do if the
UE misbehavies. I.e. if the UE simply ignores the timeout period it
received and instead of the server requested 300 seconds uses 30
seconds for the timeout period.

Is the server going to detect this? Is the server going to kick the UE
out because it misbehaves and sends liveness checks too often? On
the other hand IKEv2 RFC also allows sending liveness checks at any
time when client thinks there might be issues (for example it receives
ICMP message), so server cannot kick UE out just because it does
liveness checks too often. 

On the other hand if server asks for 30 seconds, and UE uses 300
seconds, is the server going to assume that UE is dead as it didn't
send liveness check in last 30 seconds? Is it going to free the
resources of the UE after some amount of time when it should have
received liveness check etc.

So as there is no server side behavior described in the 3gpp EPC
specification, this is more like suggestion than actual requirement.
It is similar than laws we have where you must do something, but even
if you do not there is no penalty, i.e. it is unenforceable law.

Of course in most cases the UE will follow the liveness check timeout
period requested by the EPC, as it does not have any reason not to,
but UE might still want to have some limits for those, i.e. even if
the server asks liveness checks every second, it might be good idea to
make the lower limit to something like 30 seconds... 
-- 
[email-masked]

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 26 Feb 2016 12:27:56 +0000

Hello,

3GPP mostly focuses on specifying the correct behaviour of nodes, on defining compliance test cases and relying on vendor's declaration of compliance to the test cases.

I agree that it is possible that a UE (client) can misbehave as you stated below but so far none reported this yet. So, there was no need to specify network countermeasures in 3GPP.

IMO (and this is really my speculation only as 3GPP does not say anything on this), if misbehaving UEs (clients) appear:
- the ePDG (server) could detect the misbehaving UE (client) since ePDG (server) can measure frequency of reception of the INFORMATIONAL requests without payloads. If this is a constant pattern, the operator can request vendor of the UE (client) to update firmware/software of the misbehaving UEs (clients).
- under normal circumstances, I would not expect ePDG (server) to kick misbehaving UEs (clients).
- if the ePDG (server) is overloaded with a lot of INFORMATIONAL requests without payloads, and needs to reduce the load then perhaps ePDG (server) could consider whether the UE (client) sends too frequent INFORMATION requests when reducing the load by kicking some UEs (clients) out.

In any case, the above is just internal ePDG (server) handling and can be deployed without further standardization.

Kind regards

Ivo Sedlacek

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 
Sent: Friday, February 26, 2016 12:24 PM
To: Ivo Sedlacek
Cc: Paul Wouters; [email-masked]; [email-masked]
Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK

Ivo Sedlacek writes:
> 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).
> 

Yes, but there is nothing there to say what the server will do if the UE misbehavies. I.e. if the UE simply ignores the timeout period it received and instead of the server requested 300 seconds uses 30 seconds for the timeout period.

Is the server going to detect this? Is the server going to kick the UE out because it misbehaves and sends liveness checks too often? On the other hand IKEv2 RFC also allows sending liveness checks at any time when client thinks there might be issues (for example it receives ICMP message), so server cannot kick UE out just because it does liveness checks too often. 

On the other hand if server asks for 30 seconds, and UE uses 300 seconds, is the server going to assume that UE is dead as it didn't send liveness check in last 30 seconds? Is it going to free the resources of the UE after some amount of time when it should have received liveness check etc.

So as there is no server side behavior described in the 3gpp EPC specification, this is more like suggestion than actual requirement.
It is similar than laws we have where you must do something, but even if you do not there is no penalty, i.e. it is unenforceable law.

Of course in most cases the UE will follow the liveness check timeout period requested by the EPC, as it does not have any reason not to, but UE might still want to have some limits for those, i.e. even if the server asks liveness checks every second, it might be good idea to make the lower limit to something like 30 seconds... 
--
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 26 Feb 2016 16:26:50 +0300

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 
  To: Tero Kivinen ; Paul Wouters 
  Cc: [email-masked] ; [email-masked] 
  Sent: Thursday, February 25, 2016 6:58 PM
  Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK

  Hello,

     first request       --> IDi,

                             [N(INITIAL_CONTACT)],

                             [IDr],

                             [N(IPCOMP_SUPPORTED)+],

                             [N(USE_TRANSPORT_MODE)],

                             SA, TSi, TSr,

                             [V+][N+]

                             EAP,

                             [V+][N+]

                       / --> EAP

     repeat 1..N times |

                       \ <-- EAP

     last request        --> AUTH

     last response       <-- AUTH,

                             [N(IPCOMP_SUPPORTED)],

                             [N(USE_TRANSPORT_MODE)],

                             SA, TSi, TSr,

                             [V+][N+]

   

  -------------

  .....

  7.2.2A    Liveness check

  -------------

  -------------

  ...

  ...

  -------------

  Kind regards

  Ivo Sedlacek

------------------------------------------------------------------------------

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 26 Feb 2016 13:54:38 +0000

Hello,

3GPP TS 24.302 states:

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:[email-masked]]
Sent: Friday, February 26, 2016 2:27 PM
To: Ivo Sedlacek; Tero Kivinen; Paul Wouters
Cc: [email-masked]; [email-masked]
Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK

Hi Ivo,

   If no

Regards,
Valery Smyslov.

----- Original Message -----
From: Ivo Sedlacek<mailto:[email-masked]>
To: Tero Kivinen<mailto:[email-masked]> ; Paul Wouters<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Thursday, February 25, 2016 6:58 PM
Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK

Hello,

   first request       --> IDi,

                           [N(INITIAL_CONTACT)],

                           [IDr],

                           [N(IPCOMP_SUPPORTED)+],

                           [N(USE_TRANSPORT_MODE)],

                           SA, TSi, TSr,

                           [V+][N+]

                           EAP,

                           [V+][N+]

                     / --> EAP

   repeat 1..N times |

                     \ <-- EAP

   last request        --> AUTH

   last response       <-- AUTH,

                           [N(IPCOMP_SUPPORTED)],

                           [N(USE_TRANSPORT_MODE)],

                           SA, TSi, TSr,

                           [V+][N+]

-------------

-------------

-------------

...

...

-------------

Kind regards

Ivo Sedlacek

________________________________
_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec