Subject: [Dots] Minimum heartbeat-interval

From: <[email-masked]>
Date: Wed, 4 Oct 2017 08:34:50 +0000

Dear all,

Jon made the following comment during the interim meeting: "A: (Jon Shallow): The minimum for the heartbeat should be 10s"

Actually, the use of 10s is not aligned with RFC8085 which says the following:

   An application that needs to employ keep-alive messages to deliver

   useful service over UDP in the presence of middleboxes SHOULD NOT

                                              ^^^^^^^^^^^^^^^^^^^^^^

   transmit them more frequently than once every 15 seconds and SHOULD

   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   use longer intervals when possible.

I suggest to add this NEW text to the signal-channel draft to clarify the rationale for the recommended values:

NEW:
      Note: heartbeat-interval should be tweaked to also assist DOTS
      messages for NAT traversal (SIG-010 of
      [I-D.ietf-dots-requirements]).  According to [RFC8085], keepalive
      messages must not be sent more frequently than once every 15
      seconds and should use longer intervals when possible.
      Furthermore, [RFC4787] recommends NATs to use a state timeout of 2
      minutes or longer.  From that standpoint, this specification
      recommends a minimum heartbeat-interval of 15 seconds and a
      maximum heartbeat-interval of 240 seconds.  The recommended value
      of 90 seconds is selected to anticipate the expiry of NAT states,
      while avoiding overloading the network with frequent keepalives
      for NAT state maintenance purposes.  Note that this recommended
      value is close to the one recommended for MAX_TRANSMIT_WAIT, whose
      value is derived from transmission parameters (Section 4.8.2 of
      [RFC7252]).

Thoughts?

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 4 Oct 2017 13:05:57 +0100

Hi Mohamed,

In principal I agree with your suggested updates - the minimum of 10s was an
off the cuff response, to handle the "broken" NAT timing implementations out
there.  

The Heartbeat mechanism does raise a few questions in my mind which do need
to be thought through.  On a DOTS server, using a heartbeat interval of 15
secs, with the client going away circa 10:54:30, I get

Oct 04 10:53:51 DEBG sending CoAP ping:

Oct 04 10:53:51 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS:
sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS
tid=29548 added to retransmit queue (2281ms)

Oct 04 10:53:51 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS:
received 41 bytes

Oct 04 10:53:51 ALRT got RST for message 29548

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS
tid=29548: removed

Oct 04 10:54:07 DEBG sending CoAP ping:

Oct 04 10:54:07 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS:
sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS
tid=29549 added to retransmit queue (2938ms)

Oct 04 10:54:07 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS:
received 41 bytes

Oct 04 10:54:07 ALRT got RST for message 29549

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS
tid=29549: removed

Oct 04 10:54:23 DEBG sending CoAP ping:

Oct 04 10:54:23 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS:
sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS
tid=29550 added to retransmit queue (2156ms)

Oct 04 10:54:23 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS:
received 41 bytes

Oct 04 10:54:23 ALRT got RST for message 29550

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS
tid=29550: removed

Oct 04 10:54:39 DEBG sending CoAP ping:

Oct 04 10:54:39 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS:
sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS
tid=29551 added to retransmit queue (2813ms)

Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS
tid=29551: retransmission #1

Oct 04 10:54:42 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS:
sent 41 bytes

Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS
tid=29551: retransmission #2

Oct 04 10:54:48 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS:
sent 41 bytes

Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS
tid=29551: retransmission #3

Oct 04 10:55:00 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS:
sent 41 bytes

Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS
tid=29551: retransmission #4

Oct 04 10:55:23 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS:
sent 41 bytes

Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS
tid=29551: give up after 4 attempts

Here we see the 91 seconds (dependant on the max-retransmit value being 4)
10:56:09 - 10:54:39.  There is 46 seconds after transmission #4 before the
confirmable ping request times out (12 seconds for transmission #3 before
retry transmission #4).

Question 1

==========

Should the max-retransmit actually be 3, not 4 for CON requests so that we
do not get this 46 second gap?

- CON is only used for signal configuration (infrequent, likely only to be
in peace time) and heartbeats, not mitigation requests

Question 2

=========

If the heartbeat interval is less than 91 seconds - say 60 seconds and the
first heartbeat ping is still active, should a second heartbeat be fired
off?

- I think not, but the text then needs to get updated to state the interval
is used whenever there is not a pending heartbeat response outstanding.

Question 3

=========

Heartbeat checks are being initiated by the client.  The client gets a
heartbeat timeout on the session.  The client subsequently needs to send a
PUT mitigate request.

Does the client set up a new session?

- Difficult as we are unlikely to be in peace time

- PKI exchanges are likely to fail

- the client just needs to send a non-confirmable PUT.

Question 4

=========

Scenario as Q3

Does the client re-use the old session that the heartbeats are failing on?

- The server may have sent a session close, but it never got through

Question 4

==========

When the heartbeats are initiated by the server, and the heartbeat times
out, the session is "bad", but the current mitigation request continues
until it expires.

The client may have kicked off his heartbeats at a different time, and there
likely will be a sending frequency drift over time, so the client may think
the session is still active, the server not, and the client decides it is
time to send a non-confirmable PUT to refresh the mitigation as it is about
to expire or possibly another PUT for a different IP that has just started
to get hammered - hence heartbeat failures.  

Alternatively the client decides that the reason for "bad" session (from the
client's perspective) is an attack stopping traffic getting through and
needs to do a PUT on the existing session.

So server receives a PUT (refresh or for a new IP) on a session that has
heartbeat expired.  The session contained all the negotiated PKI session
keys etc.  What should happen here?

- as the heartbeats are failing, it is safe to assume we are not in peace
time.

- I believe the session on the server needs to be kept hanging around for
some time post heartbeat time-out. For how long?

- the server may be seeing the client heartbeat messages [this may answer
how to keep "bad" session hanging around]

==========

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 04 October 2017 09:35
To: [email-masked]; Jon Shallow ([email-masked])
Subject: [Dots] Minimum heartbeat-interval

Dear all, 

Jon made the following comment during the interim meeting: "A: (Jon
Shallow): The minimum for the heartbeat should be 10s"

Actually, the use of 10s is not aligned with RFC8085 which says the
following: 

I suggest to add this NEW text to the signal-channel draft to clarify the
rationale for the recommended values: 

NEW:

      [RFC7252]).

Thoughts? 

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 5 Oct 2017 10:54:17 +0000

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers and lists the timeout results. The majority of the devices (62%) have a timeout between 2 and 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is 54 seconds.

Responses to the questions below

1) The max-retransmit parameter is negotiable and configurable,  DOTS agents can pick suitable values for max-retransmit parameter based on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).
2) No, if the DOTS agent wants to change the default heartbeat interval then the other message transmission parameters will also have to be modified.
3) The client will have to assume the session is disconnected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption
4) If heartbeat expires then the DOTS server will close the (D)TLS session, the client will have to initiate (D)TLS session resumption. The heartbeat expires only after 273 seconds (3 "CoAP ping" confirmable messages, each
"CoAP ping" re-transmitted 4 times).

Med - In the below text, recommended value should be 93 seconds instead of 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2).

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: [email-masked]; [email-masked]
Subject: Re: [Dots] Minimum heartbeat-interval

Hi Mohamed,

In principal I agree with your suggested updates - the minimum of 10s was an off the cuff response, to handle the "broken" NAT timing implementations out there.

The Heartbeat mechanism does raise a few questions in my mind which do need to be thought through.  On a DOTS server, using a heartbeat interval of 15 secs, with the client going away circa 10:54:30, I get

Oct 04 10:53:51 DEBG sending CoAP ping:
Oct 04 10:53:51 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes
Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548 added to retransmit queue (2281ms)
Oct 04 10:53:51 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes
Oct 04 10:53:51 ALRT got RST for message 29548
Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548: removed
Oct 04 10:54:07 DEBG sending CoAP ping:
Oct 04 10:54:07 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes
Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549 added to retransmit queue (2938ms)
Oct 04 10:54:07 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes
Oct 04 10:54:07 ALRT got RST for message 29549
Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549: removed
Oct 04 10:54:23 DEBG sending CoAP ping:
Oct 04 10:54:23 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes
Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550 added to retransmit queue (2156ms)
Oct 04 10:54:23 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes
Oct 04 10:54:23 ALRT got RST for message 29550
Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550: removed
Oct 04 10:54:39 DEBG sending CoAP ping:
Oct 04 10:54:39 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes
Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551 added to retransmit queue (2813ms)
Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #1
Oct 04 10:54:42 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes
Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #2
Oct 04 10:54:48 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes
Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #3
Oct 04 10:55:00 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes
Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #4
Oct 04 10:55:23 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes
Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: give up after 4 attempts

Here we see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:09 - 10:54:39.  There is 46 seconds after transmission #4 before the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

Question 1
==========
Should the max-retransmit actually be 3, not 4 for CON requests so that we do not get this 46 second gap?
- CON is only used for signal configuration (infrequent, likely only to be in peace time) and heartbeats, not mitigation requests

Question 2
=========
If the heartbeat interval is less than 91 seconds - say 60 seconds and the first heartbeat ping is still active, should a second heartbeat be fired off?
- I think not, but the text then needs to get updated to state the interval is used whenever there is not a pending heartbeat response outstanding.

Question 3
=========

Heartbeat checks are being initiated by the client.  The client gets a heartbeat timeout on the session.  The client subsequently needs to send a PUT mitigate request.

Question 4
=========

Scenario as Q3

Question 4
==========

When the heartbeats are initiated by the server, and the heartbeat times out, the session is "bad", but the current mitigation request continues until it expires.
The client may have kicked off his heartbeats at a different time, and there likely will be a sending frequency drift over time, so the client may think the session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh the mitigation as it is about to expire or possibly another PUT for a different IP that has just started to get hammered - hence heartbeat failures.
Alternatively the client decides that the reason for "bad" session (from the client's perspective) is an attack stopping traffic getting through and needs to do a PUT on the existing session.

So server receives a PUT (refresh or for a new IP) on a session that has heartbeat expired.  The session contained all the negotiated PKI session keys etc.  What should happen here?
- as the heartbeats are failing, it is safe to assume we are not in peace time.
- I believe the session on the server needs to be kept hanging around for some time post heartbeat time-out. For how long?
- the server may be seeing the client heartbeat messages [this may answer how to keep "bad" session hanging around]

==========

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 04 October 2017 09:35
To: [email-masked]<mailto:[email-masked]>; Jon Shallow ([email-masked]<mailto:[email-masked]>)
Subject: [Dots] Minimum heartbeat-interval

Dear all,

                                              ^^^^^^^^^^^^^^^^^^^^^^

NEW:

Thoughts?

Cheers,
Med

---

From: <[email-masked]>
Date: Fri, 6 Oct 2017 07:09:33 +0000

Hi Tiru, all,

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : jeudi 5 octobre 2017 12:54
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] Minimum heartbeat-interval

[Med] You are right about the configurable aspect, but the question from Jon is a good one. I interpret it in another way:

-    Should we rely solely on the missing-hb-allowed to detect a session problem?

-    Should we get rid of missing-hb-allowed, but rely on the retransmission to declare failure or not?

-    What is the advantage of cumulating both missing-hb-allowed and the retransmission procedure to declare a channel out?

2) No,
[Med] I agree that a heartbeat does not need to be fired when the first ping is still alive. We can clarify this in the draft.

if the DOTS agent wants to change the default heartbeat interval then the other message transmission parameters will also have to be modified.
[Med] I disagree here that the other parameters need to be changed. I don't see heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree that we need to tweak heartbeat-interval as a function of MAX_TRANSMIT_WAIT). As you know, MAX_TRANSMIT_WAIT can be derived from other parameters (ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_FACTOR)). This is why it does not make sense to provide a configuration for MAX_TRANSMIT_WAIT if the other parameters are provided.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Minimum heartbeat-interval

Hi Mohamed,

Question 1
==========

Question 2
=========

Question 3
=========

Question 4
=========

Scenario as Q3

Question 4
==========

==========

Regards

Jon

Dear all,

                                              ^^^^^^^^^^^^^^^^^^^^^^

NEW:

Thoughts?

Cheers,
Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 6 Oct 2017 13:07:56 +0000

Hi Med,

Please see inline [TR]

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 6, 2017 12:40 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] Minimum heartbeat-interval

Hi Tiru, all,

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : jeudi 5 octobre 2017 12:54
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] Minimum heartbeat-interval

[TR] If the DOTS agent does not receive a response to "CoAP ping" but receives other type of messages from the peer DOTS agent then a counter incremented each time there is no response to a "CoAP ping" till the counter value hits missing-hb-allowed to determine the session is defunct can be reset to zero.

[TR] If DOTS agents only rely on the retransmission mechanism then a "CoAP ping" message will only be retransmitted 4 times before concluding the session is disconnected in an interval of 93 seconds. The network under DDoS attack is likely to be congested (high packet loss and latency), hence missing-hb-allowed is used to send the "CoAP ping" more number of times (3 (ping) + 3*4 (re-transmissions) = 15 times) with sufficient time interval (93*3 = 279 seconds) to determine the session is defunct.

[TR] Please see above.

2) No,

[TR] Thanks.

[TR] I did not get the above, the draft is not providing any new configuration for MAX_TRANSMIT_WAIT. If let's say the DOTS agents decide to change the heartbeat interval to 45 seconds then the max-retransmit has to be changed to 3 to arrive at 45 second MAX_TRANSMIT_WAIT value (or other message transmission parameters ACK_TIMEOUT or ACK_RANDOM_FACTOR have to be changed to arrive at the new heartbeat interval). How can the heartbeat interval change without changing the message transmission parameters ?

-Tiru

-Tiru

Hi Mohamed,

Question 1
==========

Question 2
=========

Question 3
=========

Question 4
=========

Scenario as Q3

Question 4
==========

==========

Regards

Jon

Dear all,

                                              ^^^^^^^^^^^^^^^^^^^^^^

NEW:

Thoughts?

Cheers,
Med

---

From: <[email-masked]>
Date: Fri, 6 Oct 2017 13:42:17 +0000

Tiru,

We are on the same page for (1). I hope we will hear more voices on this before we add some text to the draft to clarify missing points.

Please see inline for (2).

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : vendredi 6 octobre 2017 15:08
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]
Objet : Re: [Dots] Minimum heartbeat-interval

Hi Med,

Please see inline [TR]

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, October 6, 2017 12:40 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Jon Shallow <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Minimum heartbeat-interval

Hi Tiru, all,

Please see inline.

Cheers,
Med

[TR] Please see above.

2) No,

[TR] Thanks.

[TR] I did not get the above, the draft is not providing any new configuration for MAX_TRANSMIT_WAIT
[Med] I was talking about heartbeat-interval.

. If let's say the DOTS agents decide to change the heartbeat interval to 45 seconds then the max-retransmit has to be changed to 3 to arrive at 45 second MAX_TRANSMIT_WAIT value (or other message transmission parameters ACK_TIMEOUT or ACK_RANDOM_FACTOR have to be changed to arrive at the new heartbeat interval).
[Med] My comment is that if heartbeat-interval was dependent on transmission parameters, then we do not need to configure it explicitly IN ADDITION to the other transmission parameter.

How can the heartbeat interval change without changing the message transmission parameters ?
[Med] I do see these two as separate parameters. The heartbeat-interval determines the frequency of sending keeplaive messages. This is an additional transmission parameter specific to heartbeat if you will.

-Tiru

-Tiru

Hi Mohamed,

Question 1
==========

Question 2
=========

Question 3
=========

Question 4
=========

Scenario as Q3

Question 4
==========

==========

Regards

Jon

Dear all,

                                              ^^^^^^^^^^^^^^^^^^^^^^

NEW:

Thoughts?

Cheers,
Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 6 Oct 2017 14:00:19 +0000

Thanks Med, agreed on (2) (no need to negotiate and configure heartbeat-interval).

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 6, 2017 7:12 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] Minimum heartbeat-interval

Tiru,

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : vendredi 6 octobre 2017 15:08
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dots] Minimum heartbeat-interval

Hi Med,

Please see inline [TR]

Hi Tiru, all,

Please see inline.

Cheers,
Med

[TR] Please see above.

2) No,

[TR] Thanks.

-Tiru

-Tiru

Hi Mohamed,

Question 1
==========

Question 2
=========

Question 3
=========

Question 4
=========

Scenario as Q3

Question 4
==========

==========

Regards

Jon

Dear all,

                                              ^^^^^^^^^^^^^^^^^^^^^^

NEW:

Thoughts?

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 6 Oct 2017 21:33:25 +0100

Hi Guys,

> Thanks Med, agreed on (2) (no need to negotiate and configure
heartbeat-interval).

If heartbeat-interval is not defined / negotiated – what happens in peace
time?  What rate should the heartbeats be sent at?

If COAP Pings are timing out – yes, the length of time before the timeout is
reported to the upper layers is dependent on max-retransmit, ack-timeout and
ack-random-factor at which point a COAP ping could get re-transmitted.   But
does the peace time COAP Ping transmission rate have to be greater or equal
to the COAP layer reporting the “Ping” CON has failed?

In war time, the next COAP Ping should be delayed until after the current
COAP Ping has expired.

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of Konda,
Tirumaleswar Reddy
Sent: 06 October 2017 15:00
To: [email-masked]; Jon Shallow; [email-masked]
Subject: Re: [Dots] Minimum heartbeat-interval

Thanks Med, agreed on (2) (no need to negotiate and configure
heartbeat-interval).

-Tiru

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, October 6, 2017 7:12 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon
Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] Minimum heartbeat-interval

Tiru,

We are on the same page for (1). I hope we will hear more voices on this
before we add some text to the draft to clarify missing points. 

Cheers,

Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
Reddy
Envoyé : vendredi 6 octobre 2017 15:08
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]
Objet : Re: [Dots] Minimum heartbeat-interval

Hi Med,

Please see inline [TR]

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, October 6, 2017 12:40 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon
Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] Minimum heartbeat-interval

Hi Tiru, all, 

Please see inline. 

Cheers,

Med

De : Konda, Tirumaleswar Reddy [ <mailto:[email-masked]>
mailto:[email-masked]] 
Envoyé : jeudi 5 octobre 2017 12:54
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN;  <mailto:[email-masked]>
[email-masked]
Objet : RE: [Dots] Minimum heartbeat-interval

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by
https://tools.ietf.org/html/rfc7925 has tested NAT behavior with various
routers and lists the timeout results. The majority of the devices (62%)
have a timeout between 2 and 2.5 minutes and the minimum timeout value
observed when packets are exchanged b/w peers in both directions is 54
seconds. 

1) The max-retransmit parameter is negotiable and configurable,  DOTS agents
can pick suitable values for max-retransmit parameter based on the
heartbeat-interval (e.g. use 3 instead of default 4 to reduce the
MAX_TRANSMIT_WAIT to 45 seconds). 

[Med] You are right about the configurable aspect, but the question from Jon
is a good one. I interpret it in another way: 

-   Should we rely solely on the missing-hb-allowed to detect a session
problem?

[TR] If the DOTS agent does not receive a response to “CoAP ping” but
receives other type of messages from the peer DOTS agent then a counter
incremented each time there is no response to a “CoAP ping” till the counter
value hits missing-hb-allowed to determine the session is defunct can be
reset to zero.

-   Should we get rid of missing-hb-allowed, but rely on the retransmission
to declare failure or not?

[TR] If DOTS agents only rely on the retransmission mechanism then a “CoAP
ping” message will only be retransmitted 4 times before concluding the
session is disconnected in an interval of 93 seconds. The network under DDoS
attack is likely to be congested (high packet loss and latency), hence
missing-hb-allowed is used to send the “CoAP ping” more number of times (3
(ping) + 3*4 (re-transmissions) = 15 times) with sufficient time interval
(93*3 = 279 seconds) to determine the session is defunct. 

-   What is the advantage of cumulating both missing-hb-allowed and the
retransmission procedure to declare a channel out?

[TR] Please see above.

2) No,

[Med] I agree that a heartbeat does not need to be fired when the first ping
is still alive. We can clarify this in the draft. 

[TR] Thanks. 

if the DOTS agent wants to change the default heartbeat interval then the
other message transmission parameters will also have to be modified. 

[Med] I disagree here that the other parameters need to be changed. I don’t
see heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree
that we need to tweak heartbeat-interval as a function of
MAX_TRANSMIT_WAIT). As you know, MAX_TRANSMIT_WAIT can be derived from other
parameters (ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) *
ACK_RANDOM_FACTOR)). This is why it does not make sense to provide a
configuration for MAX_TRANSMIT_WAIT if the other parameters are provided. 

[TR] I did not get the above, the draft is not providing any new
configuration for MAX_TRANSMIT_WAIT

. If let’s say the DOTS agents decide to change the heartbeat interval to 45
seconds then the max-retransmit has to be changed to 3 to arrive at 45
second MAX_TRANSMIT_WAIT value (or other message transmission parameters
ACK_TIMEOUT or ACK_RANDOM_FACTOR have to be changed to arrive at the new
heartbeat interval).

[Med] My comment is that if heartbeat-interval was dependent on transmission
parameters, then we do not need to configure it explicitly IN ADDITION to
the other transmission parameter.  

How can the heartbeat interval change without changing the message
transmission parameters ?

[Med] I do see these two as separate parameters. The heartbeat-interval
determines the frequency of sending keeplaive messages. This is an
additional transmission parameter specific to heartbeat if you will.

-Tiru

3) The client will have to assume the session is disconnected (see the
discussion in
https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1)
and initiate (D)TLS session resumption 

4) If heartbeat expires then the DOTS server will close the (D)TLS session,
the client will have to initiate (D)TLS session resumption. The heartbeat
expires only after 273 seconds (3 “CoAP ping” confirmable messages, each 
“CoAP ping” re-transmitted 4 times). 

Med – In the below text, recommended value should be 93 seconds instead of
90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). 

-Tiru

Hi Mohamed,

In principal I agree with your suggested updates – the minimum of 10s was an
off the cuff response, to handle the “broken” NAT timing implementations out
there.  

Here we see the 91 seconds (dependant on the max-retransmit value being 4)
10:56:09 – 10:54:39.  There is 46 seconds after transmission #4 before the
confirmable ping request times out (12 seconds for transmission #3 before
retry transmission #4).

Question 1

==========

Question 2

=========

If the heartbeat interval is less than 91 seconds – say 60 seconds and the
first heartbeat ping is still active, should a second heartbeat be fired
off?

Question 3

=========

Question 4

=========

Scenario as Q3

Question 4

==========

When the heartbeats are initiated by the server, and the heartbeat times
out, the session is “bad”, but the current mitigation request continues
until it expires.

to get hammered – hence heartbeat failures.  

Alternatively the client decides that the reason for “bad” session (from the
client’s perspective) is an attack stopping traffic getting through and
needs to do a PUT on the existing session.

- the server may be seeing the client heartbeat messages [this may answer
how to keep “bad” session hanging around]

==========

Regards

Jon

Dear all, 

Jon made the following comment during the interim meeting: “A: (Jon
Shallow): The minimum for the heartbeat should be 10s”

NEW:

      [RFC7252]).

Thoughts? 

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 7 Oct 2017 03:11:20 +0000

Hi Jon,

I meant heartbeat-interval will be defined as equivalent to MAX_TRANSMIT_WAIT but not negotiated as heartbeat-interval is derived from the message transmission parameters.

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Saturday, October 7, 2017 2:03 AM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] Minimum heartbeat-interval

Hi Guys,

> Thanks Med, agreed on (2) (no need to negotiate and configure heartbeat-interval).

If heartbeat-interval is not defined / negotiated - what happens in peace time?  What rate should the heartbeats be sent at?

If COAP Pings are timing out - yes, the length of time before the timeout is reported to the upper layers is dependent on max-retransmit, ack-timeout and ack-random-factor at which point a COAP ping could get re-transmitted.   But does the peace time COAP Ping transmission rate have to be greater or equal to the COAP layer reporting the "Ping" CON has failed?

In war time, the next COAP Ping should be delayed until after the current COAP Ping has expired.

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 06 October 2017 15:00
To: [email-masked]<mailto:[email-masked]>; Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Minimum heartbeat-interval

-Tiru

Tiru,

Cheers,
Med

Hi Med,

Please see inline [TR]

Hi Tiru, all,

Please see inline.

Cheers,
Med

[TR] Please see above.

2) No,

[TR] Thanks.

-Tiru

-Tiru

Hi Mohamed,

Question 1
==========

Question 2
=========

Question 3
=========

Question 4
=========

Scenario as Q3

Question 4
==========

==========

Regards

Jon

Dear all,

                                              ^^^^^^^^^^^^^^^^^^^^^^

NEW:

Thoughts?

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 7 Oct 2017 10:35:05 +0100

Hi Tiru,

I confess to being troubled when considering tuning the various
max-retransmit, ack-timeout and ack-random-factor values to get heartbeats
behaving as required, as this will also affect anything else using CON for
the requests.

With ack-timeout = 2, ack-random-factor = 1.5 and max-retransmit = 4 (the
defaults) and loss of response

Heartbeat Ping

3 seconds

Ping retry #1

6 seconds

Ping retry #2

12 seconds

Ping retry #3

24 seconds

Ping retry #4

48 seconds

Heartbeat Ping Timeout (after 93 seconds) reported to upper layers

In terms of NAT (or even firewall session with no NAT) keep-alive, we are
doing this with a value of 3 seconds up to 48 seconds.

I am making the assumption that the next Heartbeat Ping request (under
response loss conditions) almost immediately follows the Heartbeat Ping
Timeout, the cycles of which give up after missing-hb-allowed is exceeded
and the session is declared as dead.

When there is no loss of response

Heartbeat Ping

Small number of milli seconds

Ping Response (RST)

MAX_TRANSMIT_WAIT (93 seconds)

Heartbeat Ping

Small number of milli seconds

Ping Response (RST)

…

I propose that instead of MAX_TRANSMIT_WAIT (93 seconds), we should use the
derived 48 second gap (between Ping Retry #4 and Heartbeat Ping Timeout)
when there is no loss of response for repeating Ping.  Thoughts?

The reason for this is that you state below “the minimum timeout value
observed when packets are exchanged b/w peers in both directions is 54
seconds.”

A potential workaround to this discussion is that the spec states “To make
sure that Heartbeats work correctly, any firewall rule (whether NAT’d or
not) on a firewall sitting between the DOTS client and DOTS Server that
enables the DOTS signal channel to traverse the device MUST have an idle
session timeout value greater than the derived MAX_TRANSMIT_WAIT” 

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 07 October 2017 04:11
To: Jon Shallow; [email-masked]; [email-masked]
Subject: Re: [Dots] Minimum heartbeat-interval

Hi Jon,

I meant heartbeat-interval will be defined as equivalent to
MAX_TRANSMIT_WAIT but not negotiated as heartbeat-interval is derived from
the message transmission parameters. 

-Tiru

From: Jon Shallow [mailto:[email-masked]] 
Sent: Saturday, October 7, 2017 2:03 AM
To: Konda, Tirumaleswar Reddy <[email-masked]>;
[email-masked]; [email-masked]
Subject: RE: [Dots] Minimum heartbeat-interval

Hi Guys,

heartbeat-interval).

Regards

Jon

-Tiru

Tiru,

Cheers,

Med

Hi Med,

Please see inline [TR]

Hi Tiru, all, 

Please see inline. 

Cheers,

Med

[TR] Please see above.

2) No,

[TR] Thanks. 

-Tiru

-Tiru

Hi Mohamed,

Question 1

==========

Question 2

=========

Question 3

=========

Question 4

=========

Scenario as Q3

Question 4

==========

 

==========

Regards

Jon

Dear all, 

NEW:

      [RFC7252]).

Thoughts? 

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Oct 2017 13:08:49 +0000

Please see inline [TR]

From: Jon Shallow [mailto:[email-masked]]
Sent: Saturday, October 7, 2017 3:05 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] Minimum heartbeat-interval

Hi Tiru,

I confess to being troubled when considering tuning the various max-retransmit, ack-timeout and ack-random-factor values to get heartbeats behaving as required, as this will also affect anything else using CON for the requests.

With ack-timeout = 2, ack-random-factor = 1.5 and max-retransmit = 4 (the defaults) and loss of response
Heartbeat Ping
3 seconds
Ping retry #1
6 seconds
Ping retry #2
12 seconds
Ping retry #3
24 seconds
Ping retry #4
48 seconds
Heartbeat Ping Timeout (after 93 seconds) reported to upper layers

In terms of NAT (or even firewall session with no NAT) keep-alive, we are doing this with a value of 3 seconds up to 48 seconds.
I am making the assumption that the next Heartbeat Ping request (under response loss conditions) almost immediately follows the Heartbeat Ping Timeout, the cycles of which give up after missing-hb-allowed is exceeded and the session is declared as dead.

Heartbeat Ping
...

I propose that instead of MAX_TRANSMIT_WAIT (93 seconds), we should use the derived 48 second gap (between Ping Retry #4 and Heartbeat Ping Timeout) when there is no loss of response for repeating Ping.  Thoughts?

The reason for this is that you state below "the minimum timeout value observed when packets are exchanged b/w peers in both directions is 54 seconds."

A potential workaround to this discussion is that the spec states "To make sure that Heartbeats work correctly, any firewall rule (whether NAT'd or not) on a firewall sitting between the DOTS client and DOTS Server that enables the DOTS signal channel to traverse the device MUST have an idle session timeout value greater than the derived MAX_TRANSMIT_WAIT"

Proposed text looks good. In addition to the above change, max-retransmit can be reduced from 4 to 3 to reduce MAX_TRANSMIT_WAIT from 93 seconds to 45 seconds.

-Tiru

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 04:11
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Minimum heartbeat-interval

Hi Jon,

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Saturday, October 7, 2017 2:03 AM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Minimum heartbeat-interval

Hi Guys,

Regards

Jon

-Tiru

Tiru,

Cheers,
Med

Hi Med,

Please see inline [TR]

Hi Tiru, all,

Please see inline.

Cheers,
Med

[TR] Please see above.

2) No,

[TR] Thanks.

-Tiru

-Tiru

Hi Mohamed,

Question 1
==========

Question 2
=========

Question 3
=========

Question 4
=========

Scenario as Q3

Question 4
==========

==========

Regards

Jon

Dear all,

                                              ^^^^^^^^^^^^^^^^^^^^^^

NEW:

Thoughts?

Cheers,
Med

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 9 Oct 2017 11:42:13 -0400

On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote:
> https://tools.ietf.org/html/rfc7925 has tested NAT behavior with 
> various routers and lists the timeout results. The majority of the 
> devices (62%) have a timeout between 2 and 2.5 minutes and the minimum 
> timeout value observed when packets are exchanged b/w peers in both 
> directions is 54 seconds.
>
I'm getting different data-points for at least the minimum value. There 
still seems to be a lot of NATs out there with a timeout value of ~30 
seconds for UDP traffic (and in rare cases even lower), which suggests 
that a timeout value slightly lower than 30 seconds is what you would 
want. Google did a lot of testing around this and decided they were 
happy with the values in https://tools.ietf.org/html/rfc7675 (i.e. 30 
seconds).

Thanks

-- Flemming

> 1) The max-retransmit parameter is negotiable and configurable, DOTS 
> agents can pick suitable values for max-retransmit parameter based on 
> the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the 
> 2) No, if the DOTS agent wants to change the default heartbeat 
> interval then the other message transmission parameters will also have 
> to be modified.
>
> 4) If heartbeat expires then the DOTS server will close the (D)TLS 
> session, the client will have to initiate (D)TLS session resumption. 
> The heartbeat expires only after 273 seconds (3 “CoAP ping” 
> confirmable messages, each
> Med – In the below text, recommended value should be 93 seconds 
> instead of 90 seconds (see 
> https://tools.ietf.org/html/rfc7252#section-4.8.2).
>
> -Tiru
>
> *From:*Dots [mailto:[email-masked]] *On Behalf Of *Jon Shallow
> *Sent:* Wednesday, October 4, 2017 5:36 PM
> *To:* [email-masked]; [email-masked]
> *Subject:* Re: [Dots] Minimum heartbeat-interval
>
> Hi Mohamed,
>
> In principal I agree with your suggested updates – the minimum of 10s 
> was an off the cuff response, to handle the “broken” NAT timing 
> implementations out there.
>
> The Heartbeat mechanism does raise a few questions in my mind which do 
> need to be thought through.  On a DOTS server, using a heartbeat 
> interval of 15 secs, with the client going away circa 10:54:30, I get
>
> Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) 
> DTLS tid=29548 added to retransmit queue (2281ms)
>
> Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) 
> DTLS tid=29549 added to retransmit queue (2938ms)
>
> Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) 
> DTLS tid=29550 added to retransmit queue (2156ms)
>
> Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) 
> DTLS tid=29551 added to retransmit queue (2813ms)
>
> Here we see the 91 seconds (dependant on the max-retransmit value 
> being 4) 10:56:09 – 10:54:39.  There is 46 seconds after transmission 
> #4 before the confirmable ping request times out (12 seconds for 
> transmission #3 before retry transmission #4).
>
> Question 1
>
> ==========
>
> - CON is only used for signal configuration (infrequent, likely only 
> to be in peace time) and heartbeats, not mitigation requests
>
> Question 2
>
> =========
>
> If the heartbeat interval is less than 91 seconds – say 60 seconds and 
> the first heartbeat ping is still active, should a second heartbeat be 
> fired off?
>
> - I think not, but the text then needs to get updated to state the 
> interval is used whenever there is not a pending heartbeat response 
> outstanding.
>
> Question 3
>
> =========
>
> heartbeat timeout on the session.  The client subsequently needs to 
> send a PUT mitigate request.
>
> When the heartbeats are initiated by the server, and the heartbeat 
> times out, the session is “bad”, but the current mitigation request 
> continues until it expires.
>
> The client may have kicked off his heartbeats at a different time, and 
> there likely will be a sending frequency drift over time, so the 
> client may think the session is still active, the server not, and the 
> client decides it is time to send a non-confirmable PUT to refresh the 
> mitigation as it is about to expire or possibly another PUT for a 
> different IP that has just started to get hammered – hence heartbeat 
> failures.
>
> Alternatively the client decides that the reason for “bad” session 
> (from the client’s perspective) is an attack stopping traffic getting 
> through and needs to do a PUT on the existing session.
>
> So server receives a PUT (refresh or for a new IP) on a session that 
> has heartbeat expired.  The session contained all the negotiated PKI 
> session keys etc.  What should happen here?
>
> - I believe the session on the server needs to be kept hanging around 
> for some time post heartbeat time-out. For how long?
>
> - the server may be seeing the client heartbeat messages [this may 
> answer how to keep “bad” session hanging around]
>
> ==========
>
> Regards
>
> Jon
>
> *From:*Dots [mailto:[email-masked]] *On Behalf Of 
> [email-masked] 
> <mailto:[email-masked]>
> *Sent:* 04 October 2017 09:35
> *To:* [email-masked] <mailto:[email-masked]>; Jon Shallow 
> ([email-masked] <mailto:[email-masked]>)
> *Subject:* [Dots] Minimum heartbeat-interval
>
> Dear all,
>
> I suggest to add this NEW text to the signal-channel draft to clarify 
> the rationale for the recommended values:
>
> NEW:
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 9 Oct 2017 11:48:24 -0400

On 10/7/17 5:35 AM, Jon Shallow wrote:
> max-retransmit, ack-timeout and ack-random-factor values to get 
> heartbeats behaving as required, as this will also affect anything 
> else using CON for the requests.
>
> In terms of NAT (or even firewall session with no NAT) keep-alive, we 
> are doing this with a value of 3 seconds up to 48 seconds.
>
> response loss conditions) almost immediately follows the Heartbeat 
> Ping Timeout, the cycles of which give up after missing-hb-allowed is 
> exceeded and the session is declared as dead.
>
> I propose that instead of MAX_TRANSMIT_WAIT (93 seconds), we should 
> use the derived 48 second gap (between Ping Retry #4 and Heartbeat 
> Ping Timeout) when there is no loss of response for repeating Ping.  
> Thoughts?
>
> A potential workaround to this discussion is that the spec states “To 
> make sure that Heartbeats work correctly, any firewall rule (whether 
> NAT’d or not) on a firewall sitting between the DOTS client and DOTS 
> Server that enables the DOTS signal channel to traverse the device 
> MUST have an idle session timeout value greater than the derived 
> MAX_TRANSMIT_WAIT”
>

The problem with this approach is that you typically do not control all 
the FWs and NATs en route to your destination, let alone even know about 
them, so imposing requirements on them is unlikely to be helpful. 
Instead, you need to find a way of actually working through them.

Thanks

-- Flemming

> Regards
>
> Jon
>
> *From:*Dots [mailto: [email-masked]] *On Behalf Of *Konda, 
> Tirumaleswar Reddy
> *Sent:* 07 October 2017 04:11
> *To:* Jon Shallow; [email-masked]; [email-masked]
> MAX_TRANSMIT_WAIT but not negotiated as heartbeat-interval is derived 
> from the message transmission parameters.
>
> -Tiru
>
> *From:*Jon Shallow [mailto:[email-masked]]
> *Sent:* Saturday, October 7, 2017 2:03 AM
> *To:* Konda, Tirumaleswar Reddy <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* RE: [Dots] Minimum heartbeat-interval
>
> Hi Guys,
>
> If heartbeat-interval is not defined / negotiated – what happens in 
> peace time?  What rate should the heartbeats be sent at?
>
> If COAP Pings are timing out – yes, the length of time before the 
> timeout is reported to the upper layers is dependent on 
> max-retransmit, ack-timeout and ack-random-factor at which point a 
> COAP ping could get re-transmitted.   But does the peace time COAP 
> Ping transmission rate have to be greater or equal to the COAP layer 
> reporting the “Ping” CON has failed?
>
> *Konda, Tirumaleswar Reddy
> *Sent:* 06 October 2017 15:00
> *To:* [email-masked] 
> <mailto:[email-masked]>; Jon Shallow; [email-masked] 
> <mailto:[email-masked]>
> *From:[email-masked] 
> <mailto:[email-masked]> 
> [mailto:[email-masked]]
> *Sent:* Friday, October 6, 2017 7:12 PM
> *To:* Konda, Tirumaleswar Reddy <[email-masked] 
> <mailto:[email-masked]>>; Jon Shallow 
> <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [Dots] Minimum heartbeat-interval
>
> Tiru,
>
> We are on the same page for (1). I hope we will hear more voices on 
> this before we add some text to the draft to clarify missing points.
>
> *De :*Dots [mailto:[email-masked]] *De la part de* Konda, 
> Tirumaleswar Reddy
> *Envoyé :* vendredi 6 octobre 2017 15:08
> *À :* BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked] 
> <mailto:[email-masked]>
> *Objet :* Re: [Dots] Minimum heartbeat-interval
>
> Hi Med,
>
> Please see inline [TR]
>
> *From:[email-masked] 
> <mailto:[email-masked]> 
> [mailto:[email-masked]]
> *Sent:* Friday, October 6, 2017 12:40 PM
> *To:* Konda, Tirumaleswar Reddy <[email-masked] 
> <mailto:[email-masked]>>; Jon Shallow 
> <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [Dots] Minimum heartbeat-interval
>
> Hi Tiru, all,
>
> Please see inline.
>
> Cheers,
>
> Med
>
> *De :*Konda, Tirumaleswar Reddy 
> [mailto:[email-masked]]
> *Envoyé :* jeudi 5 octobre 2017 12:54
> *À :* Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked] 
> <mailto:[email-masked]>
> *Objet :* RE: [Dots] Minimum heartbeat-interval
>
> [Med] You are right about the configurable aspect, but the question 
> from Jon is a good one. I interpret it in another way:
>
> -Should we rely solely on the missing-hb-allowed to detect a session 
> problem?
>
> receives other type of messages from the peer DOTS agent then a 
> counter incremented each time there is no response to a “CoAP ping” 
> till the counter value hits missing-hb-allowed to determine the 
> session is defunct can be reset to zero.
>
> -Should we get rid of missing-hb-allowed, but rely on the 
> retransmission to declare failure or not?
>
> [TR] If DOTS agents only rely on the retransmission mechanism then a 
> “CoAP ping” message will only be retransmitted 4 times before 
> concluding the session is disconnected in an interval of 93 seconds. 
> The network under DDoS attack is likely to be congested (high packet 
> loss and latency), hence missing-hb-allowed is used to send the “CoAP 
> ping” more number of times (3 (ping) + 3*4 (re-transmissions) = 15 
> times) with sufficient time interval (93*3 = 279 seconds) to determine 
> the session is defunct.
>
> -What is the advantage of cumulating both missing-hb-allowed and the 
> [Med] I agree that a heartbeat does not need to be fired when the 
> first ping is still alive. We can clarify this in the draft.
>
> [TR] Thanks.
>
> if the DOTS agent wants to change the default heartbeat interval then 
> the other message transmission parameters will also have to be modified.
>
> [Med] I disagree here that the other parameters need to be changed. I 
> don’t see heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even 
> if I agree that we need to tweak heartbeat-interval as a function of 
> MAX_TRANSMIT_WAIT). As you know, MAX_TRANSMIT_WAIT can be derived from 
> other parameters (ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * 
> . If let’s say the DOTS agents decide to change the heartbeat interval 
> to 45 seconds then the max-retransmit has to be changed to 3 to arrive 
> at 45 second MAX_TRANSMIT_WAIT value (or other message transmission 
> parameters ACK_TIMEOUT or ACK_RANDOM_FACTOR have to be changed to 
> arrive at the new heartbeat interval).
>
> [Med] My comment is that if heartbeat-interval was dependent on 
> transmission parameters, then we do not need to configure it 
> explicitly IN ADDITION to the other transmission parameter.
>
> [Med] I do see these two as separate parameters. The 
> heartbeat-interval determines the frequency of sending keeplaive 
> messages. This is an additional transmission parameter specific to 
> heartbeat if you will.
>
> -Tiru
>
> *To:* [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> DTLS tid=29548: removed
> DTLS tid=29549: removed
> DTLS tid=29550: removed

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Oct 2017 15:55:03 +0000

From: Dots [mailto:[email-masked]] On Behalf Of Flemming Andreasen
Sent: Monday, October 9, 2017 9:12 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Dots] Minimum heartbeat-interval

I'm getting different data-points for at least the minimum value. There still seems to be a lot of NATs out there with a timeout value of ~30 seconds for UDP traffic (and in rare cases even lower), which suggests that a timeout value slightly lower than 30 seconds is what you would want. Google did a lot of testing around this and decided they were happy with the values in https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds).

Consent freshness has nothing to do with NAT/FW timeouts.

-Tiru

Thanks

-- Flemming

-Tiru

Hi Mohamed,

Question 1
==========

Question 2
=========

Question 3
=========

Question 4
=========

Scenario as Q3

Question 4
==========

==========

Regards

Jon

Dear all,

                                              ^^^^^^^^^^^^^^^^^^^^^^

NEW:

Thoughts?

Cheers,
Med

Dots mailing list

[email-masked]<mailto:[email-masked]>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 9 Oct 2017 12:35:48 -0400

On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote:
>
> *From:*Dots [mailto:[email-masked]] *On Behalf Of *Flemming 
> Andreasen
> *Sent:* Monday, October 9, 2017 9:12 PM
> *To:* Konda, Tirumaleswar Reddy <[email-masked]>; 
> Jon Shallow <[email-masked]>; [email-masked]; 
> [email-masked]
>     http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced
>     by https://tools.ietf.org/html/rfc7925 has tested NAT behavior
>     with various routers and lists the timeout results. The majority
>     of the devices (62%) have a timeout between 2 and 2.5 minutes and
>     the minimum timeout value observed when packets are exchanged b/w
>     peers in both directions is 54 seconds.
>
> I'm getting different data-points for at least the minimum value. 
> There still seems to be a lot of NATs out there with a timeout value 
> of ~30 seconds for UDP traffic (and in rare cases even lower), which 
> suggests that a timeout value slightly lower than 30 seconds is what 
> you would want. Google did a lot of testing around this and decided 
> they were happy with the values in https://tools.ietf.org/html/rfc7675 
> (i.e. 30 seconds).
>
You are missing the point Tiru - testing has been done (in the past and 
more recently) and a value of ~30 seconds seems to be what works for the 
majority of devices. I'll trust Google on this one.

-- Flemming

>     1) The max-retransmit parameter is negotiable and configurable,
>     DOTS agents can pick suitable values for max-retransmit parameter
>     based on the heartbeat-interval (e.g. use 3 instead of default 4
>     to reduce the MAX_TRANSMIT_WAIT to 45 seconds).
>
>     interval then the other message transmission parameters will also
>     have to be modified.
>
>     3) The client will have to assume the session is disconnected (see
>     the discussion in
>     session, the client will have to initiate (D)TLS session
>     resumption. The heartbeat expires only after 273 seconds (3 “CoAP
>     ping” confirmable messages, each
>     In principal I agree with your suggested updates – the minimum of
>     10s was an off the cuff response, to handle the “broken” NAT
>     timing implementations out there.
>
>     The Heartbeat mechanism does raise a few questions in my mind
>     which do need to be thought through.  On a DOTS server, using a
>     heartbeat interval of 15 secs, with the client going away circa
>     10:54:30, I get
>
>     Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477
>     (if1) DTLS tid=29548 added to retransmit queue (2281ms)
>
>     Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477
>     (if1) DTLS tid=29549 added to retransmit queue (2938ms)
>
>     Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477
>     (if1) DTLS tid=29550 added to retransmit queue (2156ms)
>
>     Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477
>     (if1) DTLS tid=29551 added to retransmit queue (2813ms)
>
>     Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477
>     (if1) DTLS tid=29551: give up after 4 attempts
>
>     being 4) 10:56:09 – 10:54:39. There is 46 seconds after
>     transmission #4 before the confirmable ping request times out (12
>     seconds for transmission #3 before retry transmission #4).
>
>     Question 1
>
>     ==========
>
>     - CON is only used for signal configuration (infrequent, likely
>     only to be in peace time) and heartbeats, not mitigation requests
>
>     Question 2
>
>     =========
>
>     If the heartbeat interval is less than 91 seconds – say 60 seconds
>     and the first heartbeat ping is still active, should a second
>     heartbeat be fired off?
>
>     interval is used whenever there is not a pending heartbeat
>     response outstanding.
>
>     Question 3
>
>     =========
>
>     Heartbeat checks are being initiated by the client.  The client
>     gets a heartbeat timeout on the session.  The client subsequently
>     needs to send a PUT mitigate request.
>
>     times out, the session is “bad”, but the current mitigation
>     request continues until it expires.
>
>     The client may have kicked off his heartbeats at a different time,
>     and there likely will be a sending frequency drift over time, so
>     the client may think the session is still active, the server not,
>     and the client decides it is time to send a non-confirmable PUT to
>     refresh the mitigation as it is about to expire or possibly
>     another PUT for a different IP that has just started to get
>     hammered – hence heartbeat failures.
>
>     (from the client’s perspective) is an attack stopping traffic
>     getting through and needs to do a PUT on the existing session.
>
>     So server receives a PUT (refresh or for a new IP) on a session
>     that has heartbeat expired.  The session contained all the
>     negotiated PKI session keys etc.  What should happen here?
>
>     - I believe the session on the server needs to be kept hanging
>     around for some time post heartbeat time-out. For how long?
>
>     *From:*Dots [mailto:[email-masked]] *On Behalf
>     Of [email-masked]
>     Jon made the following comment during the interim meeting: “A:
>     (Jon Shallow): The minimum for the heartbeat should be 10s”
>
>     I suggest to add this NEW text to the signal-channel draft to
>     clarify the rationale for the recommended values:
>
>     NEW:
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: kaname nishizuka <[email-masked]>
Date: Tue, 10 Oct 2017 12:31:37 +0900

I agree with Flemming's suggestion.
Practically, the timeout will be set to ~30 seconds by operators like us.

regards,
kaname

On 2017/10/10 1:35, Flemming Andreasen wrote:
>> *From:*Dots [mailto:[email-masked]] *On Behalf Of *Flemming Andreasen
>> *To:* Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]; [email-masked]
> You are missing the point Tiru - testing has been done (in the past and more recently) and a value of ~30 seconds seems to be what works for the majority of devices. I'll trust Google on this one.
>
> -- Flemming
>
>
>> -Tiru
>>
>>
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>
>>     4) If heartbeat expires then the DOTS server will close the (D)TLS session, the client will have to initiate (D)TLS session resumption. The heartbeat expires only after 273 seconds (3 “CoAP ping” confirmable messages, each
>>     Med – In the below text, recommended value should be 93 seconds instead of 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2).
>>
>>     -Tiru
>>
>>     *To:* [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>>     In principal I agree with your suggested updates – the minimum of 10s was an off the cuff response, to handle the “broken” NAT timing implementations out there.
>>
>>     Here we see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:09 – 10:54:39.  There is 46 seconds after transmission #4 before the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).
>>
>>     Question 1
>>
>>     ==========
>>
>>     If the heartbeat interval is less than 91 seconds – say 60 seconds and the first heartbeat ping is still active, should a second heartbeat be fired off?
>>
>>     When the heartbeats are initiated by the server, and the heartbeat times out, the session is “bad”, but the current mitigation request continues until it expires.
>>
>>     The client may have kicked off his heartbeats at a different time, and there likely will be a sending frequency drift over time, so the client may think the session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh the mitigation as it is about to expire or possibly another PUT for a different IP that has just started to get hammered – hence heartbeat failures.
>>
>>     Alternatively the client decides that the reason for “bad” session (from the client’s perspective) is an attack stopping traffic getting through and needs to do a PUT on the existing session.
>>
>>     - the server may be seeing the client heartbeat messages [this may answer how to keep “bad” session hanging around]
>>
>>     ==========
>>
>>     Regards
>>
>>     Jon
>>
>>     *From:*Dots [mailto:[email-masked]] *On Behalf Of [email-masked] <mailto:[email-masked]>
>>     *To:* [email-masked] <mailto:[email-masked]>; Jon Shallow ([email-masked] <mailto:[email-masked]>)
>>     Jon made the following comment during the interim meeting: “A: (Jon Shallow): The minimum for the heartbeat should be 10s”
>>

---

From: "Teague, Nik" <[email-masked]>
Date: Tue, 10 Oct 2017 09:05:04 +0000

+1 for ~30s

On 10 Oct 2017, at 04:31, kaname nishizuka <[email-masked]<mailto:[email-masked]>> wrote:

regards,
kaname

To: Konda, Tirumaleswar Reddy <[email-masked]><mailto:[email-masked]>; Jon Shallow <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

-- Flemming

-Tiru

Thanks

-- Flemming

-Tiru

Hi Mohamed,

Question 1
==========

Question 2
=========

Question 3
=========

Question 4
=========

Scenario as Q3

Question 4
==========

==========

Regards

Jon

Dear all,

                                              ^^^^^^^^^^^^^^^^^^^^^^

NEW:

Thoughts?

Cheers,
Med

Dots mailing list

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Oct 2017 10:15:51 +0100

I also agree - my experience since the 80's is a (firewall/NAT) UDP session
timeout value default of 30 seconds - RFC4787 came out some 20 years later
in 2007.

The "heartbeat-interval" needs to be retained - with a minimum value of less
than 30 seconds (perhaps 15 seconds) so that DOTS signal will work through
(?broken?) firewalls/NAT devices that maintain some sort of state.  Even if
the heartbeat is every 30 seconds, this is a packet of less than 100 bytes
every 30 seconds - this is not going to add to a DDoS situation.

I think that text similar to the following also needs to be added

"A heartbeat is not allowed to be transmitted while a previous heartbeat has
not been responded to - which could be longer than the heartbeat interval if
there is packet loss and could be up to MAX_TRANSMIT_WAIT (RFC7252) seconds.
If MAX_TRANSMIT_WAIT is greater than the heartbeat interval and the previous
heartbeat has had no response, then the next heartbeat should be sent as
soon as possible.  Otherwise heartbeats should be sent no more frequently
than the heartbeat interval." 

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of kaname nishizuka
Sent: 10 October 2017 04:32
To: Flemming Andreasen; Konda, Tirumaleswar Reddy; Jon Shallow;
[email-masked]; [email-masked]
Subject: Re: [Dots] Minimum heartbeat-interval

regards,
kaname

From: Dots [mailto:[email-masked]] On Behalf Of Flemming Andreasen
Sent: Monday, October 9, 2017 9:12 PM
To: Konda, Tirumaleswar Reddy  <mailto:[email-masked]>
<[email-masked]>; Jon Shallow
<mailto:[email-masked]> <[email-masked]>;
[email-masked]; [email-masked]
Subject: Re: [Dots] Minimum heartbeat-interval

I'm getting different data-points for at least the minimum value. There
still seems to be a lot of NATs out there with a timeout value of ~30
seconds for UDP traffic (and in rare cases even lower), which suggests that
a timeout value slightly lower than 30 seconds is what you would want.
Google did a lot of testing around this and decided they were happy with the
values in https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds). 

You are missing the point Tiru - testing has been done (in the past and more
recently) and a value of ~30 seconds seems to be what works for the majority
of devices. I'll trust Google on this one. 

-- Flemming 

-Tiru

Thanks 

-- Flemming 

2) No, if the DOTS agent wants to change the default heartbeat interval then
the other message transmission parameters will also have to be modified. 

4) If heartbeat expires then the DOTS server will close the (D)TLS session,
the client will have to initiate (D)TLS session resumption. The heartbeat
expires only after 273 seconds (3 "CoAP ping" confirmable messages, each 
"CoAP ping" re-transmitted 4 times). 

Med - In the below text, recommended value should be 93 seconds instead of
90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). 

-Tiru

Hi Mohamed,

Question 1

==========

Question 2

=========

Question 3

=========

Question 4

=========

Scenario as Q3

Question 4

==========

 

==========

Regards

Jon

Dear all, 

NEW:

      [RFC7252]).

Thoughts? 

Cheers,

Med

---

From: <[email-masked]>
Date: Tue, 10 Oct 2017 09:43:00 +0000

Hi all,

Here is an updated text to echo the voices heard so far. Please double check it:

NEW:
      Note: heartbeat-interval should be tweaked to also assist DOTS
      messages for NAT traversal (SIG-010 of
      [I-D.ietf-dots-requirements]).  According to [RFC8085], keepalive
      messages must not be sent more frequently than once every 15
      seconds and should use longer intervals when possible.
      Furthermore, [RFC4787] recommends NATs to use a state timeout of 2
      minutes or longer.  From that standpoint, this specification
      recommends a minimum heartbeat-interval of 15 seconds and a
      maximum heartbeat-interval of 240 seconds.  The recommended value
      of 30 seconds is selected to be aligned with common practices for
      services suffering from similar issues (e.g., [RFc7675]).
      A heartbeat-interval of 30s may be seen as too chatty in some deployments.
      For such deployments, DOTS agents may negotiate longer heartbeat-interval
      values to avoid overloading the network with too frequent keepalives.

Of course, the text proposed by Jon will also be integrated in the next iteration of the draft (that point was already agreed).

Thank you.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 10 octobre 2017 11:16
À : 'kaname nishizuka'; Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed IMT/OLN; 'Flemming Andreasen'; [email-masked]
Objet : RE: [Dots] Minimum heartbeat-interval

I also agree - my experience since the 80's is a (firewall/NAT) UDP session timeout value default of 30 seconds - RFC4787 came out some 20 years later in 2007.

The "heartbeat-interval" needs to be retained - with a minimum value of less than 30 seconds (perhaps 15 seconds) so that DOTS signal will work through (?broken?) firewalls/NAT devices that maintain some sort of state.  Even if the heartbeat is every 30 seconds, this is a packet of less than 100 bytes every 30 seconds - this is not going to add to a DDoS situation.

"A heartbeat is not allowed to be transmitted while a previous heartbeat has not been responded to - which could be longer than the heartbeat interval if there is packet loss and could be up to MAX_TRANSMIT_WAIT (RFC7252) seconds.  If MAX_TRANSMIT_WAIT is greater than the heartbeat interval and the previous heartbeat has had no response, then the next heartbeat should be sent as soon as possible.  Otherwise heartbeats should be sent no more frequently than the heartbeat interval."

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of kaname nishizuka
Sent: 10 October 2017 04:32
To: Flemming Andreasen; Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Minimum heartbeat-interval

regards,
kaname

-- Flemming

-Tiru

Thanks

-- Flemming

-Tiru

Hi Mohamed,

Question 1
==========

Question 2
=========

Question 3
=========

Question 4
=========

Scenario as Q3

Question 4
==========

==========

Regards

Jon

Dear all,

                                              ^^^^^^^^^^^^^^^^^^^^^^

NEW:

Thoughts?

Cheers,
Med

Dots mailing list

Dots mailing list

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Oct 2017 11:47:31 +0000

Hi Flemming,

Please see inline

From: Flemming Andreasen [mailto:[email-masked]]
Sent: Monday, October 9, 2017 10:06 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Dots] Minimum heartbeat-interval

[TR]
I see that QUIC is using 15 to 30 seconds keepalives to handle middlebox idle timeout (https://tools.ietf.org/html/draft-ietf-quic-transport-06#section-8.7) but I don't see any reference to the results published by Google,  Can you please point to the test results by Google to refer in the DOTS signal channel draft?
(http://conferences.sigcomm.org/imc/2010/papers/p260.pdf results indicate 30 seconds is only applicable when there is only outbound traffic
and no incoming traffic).

-Tiru

-- Flemming

-Tiru

Thanks

-- Flemming

-Tiru

Hi Mohamed,

Question 1
==========

Question 2
=========

Question 3
=========

Question 4
=========

Scenario as Q3

Question 4
==========

==========

Regards

Jon

Dear all,

                                              ^^^^^^^^^^^^^^^^^^^^^^

NEW:

Thoughts?

Cheers,
Med

Dots mailing list

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Oct 2017 11:50:02 +0000

Hi Kaname,

Is the timeout 30 second fixed irrespective of incoming and outgoing traffic seen by the NAT ?
Any specific reason for not following the recommendations given in RFC4787 ?
http://conferences.sigcomm.org/imc/2010/papers/p260.pdf  shows different results for only outbound traffic verses inbound and outbound traffic.

-Tiru

From: kaname nishizuka [mailto:[email-masked]]
Sent: Tuesday, October 10, 2017 9:02 AM
To: Flemming Andreasen <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Jon Shallow <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Minimum heartbeat-interval

regards,
kaname

-- Flemming

-Tiru

Thanks

-- Flemming

-Tiru

Hi Mohamed,

Question 1
==========

Question 2
=========

Question 3
=========

Question 4
=========

Scenario as Q3

Question 4
==========

==========

Regards

Jon

Dear all,

                                              ^^^^^^^^^^^^^^^^^^^^^^

NEW:

Thoughts?

Cheers,
Med

Dots mailing list

Dots mailing list

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Oct 2017 12:02:35 +0000

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Tuesday, October 10, 2017 2:46 PM
To: 'kaname nishizuka' <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; 'Flemming Andreasen' <[email-masked]>; [email-masked]
Subject: Re: [Dots] Minimum heartbeat-interval

[TR] I don't think the above logic addresses the 30 second NAT/FW idle timeout problem, the recommended default max-retransmit has to be reduced to 2 to get a MAX_TRANSMIT_WAIT time of 21 seconds.

-Tiru

Regards

Jon

regards,
kaname

-- Flemming

-Tiru

Thanks

-- Flemming

-Tiru

Hi Mohamed,

Question 1
==========

Question 2
=========

Question 3
=========

Question 4
=========

Scenario as Q3

Question 4
==========

==========

Regards

Jon

Dear all,

                                              ^^^^^^^^^^^^^^^^^^^^^^

NEW:
      minutes or longer.  >From that standpoint, this specification

Thoughts?

Cheers,
Med

Dots mailing list

Dots mailing list

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 24 Oct 2017 21:49:05 -0400

On 10/10/17 7:47 AM, Konda, Tirumaleswar Reddy wrote:
>
> Hi Flemming,
>
> Please see inline
>
> *From:*Flemming Andreasen [mailto:[email-masked]]
> *Sent:* Monday, October 9, 2017 10:06 PM
>     *To:* Konda, Tirumaleswar Reddy
>     <[email-masked]>
>     <mailto:[email-masked]>; Jon Shallow
>     <[email-masked]> <mailto:[email-masked]>;
>     [email-masked]
>         http://conferences.sigcomm.org/imc/2010/papers/p260.pdfreferenced
>         by https://tools.ietf.org/html/rfc7925has tested NAT behavior
>         with various routers and lists the timeout results. The
>         majority of the devices (62%) have a timeout between 2 and 2.5
>         minutes and the minimum timeout value observed when packets
>         are exchanged b/w peers in both directions is 54 seconds.
>
>     There still seems to be a lot of NATs out there with a timeout
>     value of ~30 seconds for UDP traffic (and in rare cases even
>     lower), which suggests that a timeout value slightly lower than 30
>     seconds is what you would want. Google did a lot of testing around
>     this and decided they were happy with the values in
>     https://tools.ietf.org/html/rfc7675(i.e. 30 seconds).
>
> You are missing the point Tiru - testing has been done (in the past 
> and more recently) and a value of ~30 seconds seems to be what works 
> for the majority of devices. I'll trust Google on this one.
>
> [TR]
>
> I see that QUIC is using 15 to 30 seconds keepalives to handle 
> middlebox idle timeout 
> (https://tools.ietf.org/html/draft-ietf-quic-transport-06#section-8.7) 
> but I don’t see any reference to the results published by Google, Can 
> you please point to the test results by Google to refer in the DOTS 
> signal channel draft?
>
Sorry for the delay. In any case, if you look at slide 10 in 
https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf you 
will see a nice graph of the test results Google ran. There is a small 
bump at the 30 second mark and hence that's where the value comes from.

> (http://conferences.sigcomm.org/imc/2010/papers/p260.pdfresults 
> indicate 30 seconds is only applicable when there is only outbound 
> traffic
>
Makes sense - as long as traffic is flowing in either direction, I would 
not expect the binding to time-out.

Thanks

-- Flemming

>         1) The max-retransmit parameter is negotiable and
>         configurable,  DOTS agents can pick suitable values for
>         max-retransmit parameter based on the heartbeat-interval (e.g.
>         use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to
>         45 seconds).
>
>         interval then the other message transmission parameters will
>         also have to be modified.
>
>         3) The client will have to assume the session is disconnected
>         (see the discussion in
>         4) If heartbeat expires then the DOTS server will close the
>         (D)TLS session, the client will have to initiate (D)TLS
>         session resumption. The heartbeat expires only after 273
>         seconds (3 “CoAP ping” confirmable messages, each
>         Med – In the below text, recommended value should be 93
>         seconds instead of 90 seconds (see
>         In principal I agree with your suggested updates – the minimum
>         of 10s was an off the cuff response, to handle the “broken”
>         NAT timing implementations out there.
>
>         which do need to be thought through.  On a DOTS server, using
>         a heartbeat interval of 15 secs, with the client going away
>         circa 10:54:30, I get
>
>         Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS: sent 41 bytes
>
>         Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS tid=29548 added to retransmit
>         queue (2281ms)
>
>         Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS: received 41 bytes
>
>         Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS tid=29548: removed
>
>         Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS: sent 41 bytes
>
>         Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS tid=29549 added to retransmit
>         queue (2938ms)
>
>         Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS: received 41 bytes
>
>         Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS tid=29549: removed
>
>         Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS: sent 41 bytes
>
>         Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS tid=29550 added to retransmit
>         queue (2156ms)
>
>         Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS: received 41 bytes
>
>         Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS tid=29550: removed
>
>         Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS: sent 41 bytes
>
>         Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS tid=29551 added to retransmit
>         queue (2813ms)
>
>         Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #1
>
>         Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS: sent 41 bytes
>
>         Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #2
>
>         Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS: sent 41 bytes
>
>         Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #3
>
>         Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS: sent 41 bytes
>
>         Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #4
>
>         Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS: sent 41 bytes
>
>         Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <->
>         192.168.0.1:54477 (if1) DTLS tid=29551: give up after 4 attempts
>
>         Here we see the 91 seconds (dependant on the max-retransmit
>         value being 4) 10:56:09 – 10:54:39.  There is 46 seconds after
>         transmission #4 before the confirmable ping request times out
>         (12 seconds for transmission #3 before retry transmission #4).
>
>         Question 1
>
>         ==========
>
>         Should the max-retransmit actually be 3, not 4 for CON
>         requests so that we do not get this 46 second gap?
>
>         - CON is only used for signal configuration (infrequent,
>         likely only to be in peace time) and heartbeats, not
>         mitigation requests
>
>         Question 2
>
>         =========
>
>         If the heartbeat interval is less than 91 seconds – say 60
>         seconds and the first heartbeat ping is still active, should a
>         second heartbeat be fired off?
>
>         - I think not, but the text then needs to get updated to state
>         the interval is used whenever there is not a pending heartbeat
>         response outstanding.
>
>         Question 3
>
>         =========
>
>         Heartbeat checks are being initiated by the client.  The
>         client gets a heartbeat timeout on the session.  The client
>         subsequently needs to send a PUT mitigate request.
>
>         When the heartbeats are initiated by the server, and the
>         heartbeat times out, the session is “bad”, but the current
>         mitigation request continues until it expires.
>
>         The client may have kicked off his heartbeats at a different
>         time, and there likely will be a sending frequency drift over
>         time, so the client may think the session is still active, the
>         server not, and the client decides it is time to send a
>         non-confirmable PUT to refresh the mitigation as it is about
>         to expire or possibly another PUT for a different IP that has
>         just started to get hammered – hence heartbeat failures.
>
>         Alternatively the client decides that the reason for “bad”
>         session (from the client’s perspective) is an attack stopping
>         traffic getting through and needs to do a PUT on the existing
>         session.
>
>         So server receives a PUT (refresh or for a new IP) on a
>         session that has heartbeat expired.  The session contained all
>         the negotiated PKI session keys etc.  What should happen here?
>
>         - the server may be seeing the client heartbeat messages [this
>         may answer how to keep “bad” session hanging around]
>
>         ==========
>
>         Regards
>
>         Jon
>
>         *From:*Dots [mailto:[email-masked]] *On
>         Behalf Of [email-masked]

---

From: <[email-masked]>
Date: Wed, 25 Oct 2017 06:06:58 +0000

Flemming,

Thank you for the pointers.

FWIW, we have included this text in the latest version of the signal draft as per the outcome of this discussion:

      [I-D.ietf-dots-requirements<https://tools.ietf.org/html/draft-ietf-dots-signal-channel-05#ref-I-D.ietf-dots-requirements>]).  According to [RFC8085<https://tools.ietf.org/html/rfc8085>], keepalive

      Furthermore, [RFC4787<https://tools.ietf.org/html/rfc4787>] recommends NATs to use a state timeout of 2
      minutes or longer, but experience shows that sending packets every
      15 to 30 seconds is necessary to prevent the majority of
      middleboxes from losing state for UDP flows.  From that
      standpoint, this specification recommends a minimum heartbeat-
      interval of 15 seconds and a maximum heartbeat-interval of 240
      seconds.  The recommended value of 30 seconds is selected to
      anticipate the expiry of NAT state.

      A heartbeat-interval of 30 second may be seen as too chatty in
      some deployments.  For such deployments, DOTS agents may negotiate
      longer heartbeat-interval values to avoid overloading the network
      with too frequent keepalives.

Please let us know if changes are still required to address your comment. Thanks.

Cheers,
Med

De : Flemming Andreasen [mailto:[email-masked]]
Envoyé : mercredi 25 octobre 2017 03:49
À : Konda, Tirumaleswar Reddy; Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : Re: [Dots] Minimum heartbeat-interval

Please see inline

[TR]
I see that QUIC is using 15 to 30 seconds keepalives to handle middlebox idle timeout (https://tools.ietf.org/html/draft-ietf-quic-transport-06#section-8.7) but I don't see any reference to the results published by Google,  Can you please point to the test results by Google to refer in the DOTS signal channel draft?
Sorry for the delay. In any case, if you look at slide 10 in https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf you will see a nice graph of the test results Google ran. There is a small bump at the 30 second mark and hence that's where the value comes from.

(http://conferences.sigcomm.org/imc/2010/papers/p260.pdf results indicate 30 seconds is only applicable when there is only outbound traffic
and no incoming traffic).
Makes sense - as long as traffic is flowing in either direction, I would not expect the binding to time-out.

Thanks

-- Flemming

-Tiru

-- Flemming

-Tiru

Thanks

-- Flemming

-Tiru

Hi Mohamed,

Question 1
==========

Question 2
=========

Question 3
=========

Question 4
=========

Scenario as Q3

Question 4
==========

==========

Regards

Jon

Dear all,

                                              ^^^^^^^^^^^^^^^^^^^^^^

NEW:

Thoughts?

Cheers,
Med

Dots mailing list