Subject: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)

From: <[email-masked]>
Date: Fri, 19 Jul 2019 06:57:23 +0000

Hi Ben, chairs, all, 

(restricting the discussion to the AD/chairs/WG)

* Status:

All DISCUSS points from Mirja's review were fixed, except the one discussed in this message.

* Pending Point: 

Rather than going into much details, I consider the following as the summary of the remaining DISCUSS point from Mirja:

> I believe there are flaws in the design. First it’s a layer violation, but
> if more an idealistic concern but usually designing in layers is a good
> approach. But more importantly, you end up with un-frequent messages which
> may still terminate the connection at some point, while what you want is
> to simply send messages frequently in an unreliable fashion but a low rate
> until the attack is over.

* Discussion: 

(1) First of all, let's remind that RFC7252 does not define how CoAP ping must be used. It does only say: 

==
      Provoking a Reset
      message (e.g., by sending an Empty Confirmable message) is also
      useful as an inexpensive check of the liveness of an endpoint
      ("CoAP ping").
==

How the liveness is assessed is left to applications. So, there is ** no layer violation **. 

(2) What we need isn't (text from Mirja):

> to simply send messages frequently in an unreliable fashion but a low rate
> until the attack is over "

It is actually the other way around. The spec says: 

  "... This is particularly useful for DOTS
   servers that might want to reduce heartbeat frequency or cease
   heartbeat exchanges when an active DOTS client has not requested
   mitigation."

What we want can be formalized as: 
 - Taking into account DDoS traffic conditions, a check to assess the liveness of the peer DOTS agent + maintain NAT/FW state on on-path devices.

An much more elaborated version is documented in SIG-004 of RFC 8612.

* My analysis: 

- The intended functionality is naturally provided by existing CoAP messages.
- Informed WG decision: The WG spent a lot of cycles when specifying the current behavior to be meet the requirements set in RFC8612.
- Why not an alternative design: We can always define messages with duplicated functionality, but that is not a good design approach especially when there is no evident benefit. 
- The specification is not broken: it was implemented and tested.

And a logistic comment: this issue fits IMHO under the non-discuss criteria in https://www.ietf.org/blog/discuss-criteria-iesg-review/#stand-undisc. 

* What's Next?

As an editor, I don't think a change is needed but I'd like to hear from Ben, chairs, and the WG. 

Please share your thoughts and whether you agree/disagree with the above analysis. 

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 19 Jul 2019 09:53:38 +0100

Hi there,

I concur with what Med is saying.

"If it is not broken, do not fix it".

IETF 103 Interop ( https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00.pdf ) did exhaustively test out the heartbeat mechanism (and the interactions with other parts of the DOTS protocol) under attack scenarios and found that the then version of the DOTS signal draft worked as expected.

Yes, we can move the heartbeat mechanism into the DOTS layer, but that will require changes to the DOTS signal draft and will again need to be thoroughly tested for functionality (in particular interaction with other parts of the protocol definitions) under adverse network conditions.

Regards

Jon

> -----Original Message-----
> From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
> Sent: 19 July 2019 07:57
> To: Benjamin Kaduk ([email-masked]); [email-masked]; [email-masked]
> Subject: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> 
> Hi Ben, chairs, all,
> 
> Rather than going into much details, I consider the following as the summary
> of the remaining DISCUSS point from Mirja:
> 
>  - Taking into account DDoS traffic conditions, a check to assess the liveness of
> the peer DOTS agent + maintain NAT/FW state on on-path devices.
> 
> - Informed WG decision: The WG spent a lot of cycles when specifying the
> current behavior to be meet the requirements set in RFC8612.
> - Why not an alternative design: We can always define messages with
> duplicated functionality, but that is not a good design approach especially
> when there is no evident benefit.
> And a logistic comment: this issue fits IMHO under the non-discuss criteria in
> https://www.ietf.org/blog/discuss-criteria-iesg-review/#stand-undisc.
> 
> * What's Next?
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 19 Jul 2019 14:42:50 +0300

Hi Med,

I believe Mirja's main point was that if you use liveness check mechanism in the transport layer,
then if it reports that liveness check fails, then it _also_ closes the transport session.

Quotes from her emails:
"Yes, as Coap Ping is used, the agent should not only conclude that the DOTS signal session is disconnected but also the Coap session and not send any further Coap messages anymore."

and

"Actually to my understanding this will not work. Both TCP heartbeat and Coap Ping are transmitted reliably. If you don’t receive an ack for these transmissions you are not able to send any additional messages and can only close the connection."

I'm not familiar with CoAP, but I suspect she's right about TCP - if TCP layer itself doesn't receive ACK
for the sent data after several retransmissions, the connection is closed.

As far as I understand the current draft allows underlying liveness check to fail and has a parameter
to restart this check several times if this happens. It seems that a new transport session will be 
created in this case (at least if TCP is used). In my reading of the draft this seems not been assumed,
it is assumed that the session remains the same. So, I think that main Mirja's concern is that it won't
work (at least with TCP).

I didn't participate in the WG discussion on this, so I don't know what was discussed
regarding this issue. If it was discussed and the WG has come to conclusion that this is 
not an issue, then I believe more text should be added to the draft so, that people
like Mirja, who didn't participate in the discussion, don't have any concerns while reading the draft.

Regards,
Valery.

> From: [email-masked]
> <[email-masked]>
> Sent: Friday, July 19, 2019 9:57 AM
> To: Benjamin Kaduk ([email-masked]) <[email-masked]>; dots-
> [email-masked]; [email-masked]
> Subject: Mirja's DISCUSS: Pending Point (AD Help Needed)
> 
> Hi Ben, chairs, all,
> 
> > I believe there are flaws in the design. First it’s a layer violation,
> > but if more an idealistic concern but usually designing in layers is a
> > good approach. But more importantly, you end up with un-frequent
> > messages which may still terminate the connection at some point, while
> > what you want is to simply send messages frequently in an unreliable
> > fashion but a low rate until the attack is over.
> 
> * Discussion:
> 
> > to simply send messages frequently in an unreliable fashion but a low
> > rate until the attack is over "
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 19 Jul 2019 12:05:38 +0000

Hi Valery,

The message transmission parameters including missing-hb-allowed is only for UDP transport (not for TCP). For the UDP, she is suggesting us to go with a mechanism that checks both side of the connectivity using non-confirmable message with ping and pong at the application layer instead of relying on the CoAP ping/pong. 

Cheers,
-Tiru

> From: Dots <[email-masked]> On Behalf Of Valery Smyslov
> Sent: Friday, July 19, 2019 5:13 PM
> To: [email-masked]; 'Benjamin Kaduk' <[email-masked]>;
> [email-masked]; [email-masked]
> Subject: Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> 
> 
> 
> Hi Med,
> 
> I believe Mirja's main point was that if you use liveness check mechanism in
> the transport layer, then if it reports that liveness check fails, then it _also_
> closes the transport session.
> 
> Quotes from her emails:
> "Yes, as Coap Ping is used, the agent should not only conclude that the DOTS
> signal session is disconnected but also the Coap session and not send any
> further Coap messages anymore."
> 
> and
> 
> "Actually to my understanding this will not work. Both TCP heartbeat and
> Coap Ping are transmitted reliably. If you don’t receive an ack for these
> transmissions you are not able to send any additional messages and can only
> close the connection."
> 
> I'm not familiar with CoAP, but I suspect she's right about TCP - if TCP layer
> itself doesn't receive ACK for the sent data after several retransmissions, the
> connection is closed.
> 
> As far as I understand the current draft allows underlying liveness check to
> fail and has a parameter to restart this check several times if this happens. It
> seems that a new transport session will be created in this case (at least if TCP
> is used). In my reading of the draft this seems not been assumed, it is
> assumed that the session remains the same. So, I think that main Mirja's
> concern is that it won't work (at least with TCP).
> 
> I didn't participate in the WG discussion on this, so I don't know what was
> discussed regarding this issue. If it was discussed and the WG has come to
> conclusion that this is not an issue, then I believe more text should be added
> to the draft so, that people like Mirja, who didn't participate in the discussion,
> don't have any concerns while reading the draft.
> 
> Regards,
> Valery.
> 
> 
> 
> 
> > Rather than going into much details, I consider the following as the
> > summary of the remaining DISCUSS point from Mirja:
> >
> > > I believe there are flaws in the design. First it’s a layer
> > > violation, but if more an idealistic concern but usually designing
> > > in layers is a good approach. But more importantly, you end up with
> > > un-frequent messages which may still terminate the connection at
> > > some point, while what you want is to simply send messages
> > > frequently in an unreliable fashion but a low rate until the attack is over.
> >
> > * Discussion:
> >
> > > to simply send messages frequently in an unreliable fashion but a
> > > low rate until the attack is over "
> >
> >  - Taking into account DDoS traffic conditions, a check to assess the
> > liveness of the peer DOTS agent + maintain NAT/FW state on on-path
> devices.
> >
> > - Informed WG decision: The WG spent a lot of cycles when specifying
> > the current behavior to be meet the requirements set in RFC8612.
> > duplicated functionality, but that is not a good design approach
> > especially when there is no evident benefit.
> > And a logistic comment: this issue fits IMHO under the non-discuss
> > criteria in https://www.ietf.org/blog/discuss-criteria-iesg-review/#stand-
> undisc.
> >
> > * What's Next?
> >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 19 Jul 2019 12:35:35 +0000

Hi Med,

I agree with all your responses except the alternate design is a duplicate functionality. The alternate design proposed by her to use non-confirmable message with ping and pong at the application layer itself will not work in the first place.
The client can perform application level ping/pong (e.g. GET /heartbeat) but the server cannot perform application level ping/ping. The server cannot send non-confirmable requests or empty messages to the client.

1) As per RFC7252, client can only send requests, and the server can only send responses.
2) (Section 4.3 in RFC7252) A Non-confirmable message always carries either a request or response and MUST NOT be Empty.  A Non-confirmable message MUST NOT be acknowledged by the recipient.
3) (Section 4.3 in RFC7252) Rejecting a Non-confirmable message MAY involve sending a matching Reset message, and apart from the Reset message the rejected message MUST be silently ignored.

1), 2) and 3) make non-confirmable ping at the application layer from server impossible to use.

Cheers,
-Tiru

> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Friday, July 19, 2019 12:27 PM
>  - Taking into account DDoS traffic conditions, a check to assess the liveness
> of the peer DOTS agent + maintain NAT/FW state on on-path devices.
>

---

From: <[email-masked]>
Date: Fri, 19 Jul 2019 13:02:54 +0000

Re-,

Good point. A server can only send an empty confirmable message. 

This concludes there is no alternate approach. 

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : vendredi 19 juillet 2019 14:36
> À : BOUCADAIR Mohamed TGI/OLN; Benjamin Kaduk ([email-masked]); dots-
> Objet : RE: Mirja's DISCUSS: Pending Point (AD Help Needed)
> 
> Hi Med,
> 
> I agree with all your responses except the alternate design is a duplicate
> functionality. The alternate design proposed by her to use non-confirmable
> message with ping and pong at the application layer itself will not work
> in the first place.
> The client can perform application level ping/pong (e.g. GET /heartbeat)
> but the server cannot perform application level ping/ping. The server
> cannot send non-confirmable requests or empty messages to the client.
> 
> 2) (Section 4.3 in RFC7252) A Non-confirmable message always carries
> either a request or response and MUST NOT be Empty.  A Non-confirmable
> message MUST NOT be acknowledged by the recipient.
> 3) (Section 4.3 in RFC7252) Rejecting a Non-confirmable message MAY
> involve sending a matching Reset message, and apart from the Reset message
> the rejected message MUST be silently ignored.
> 
> > All DISCUSS points from Mirja's review were fixed, except the one
> discussed
> > in this message.
> >
> > * Pending Point:
> >
> summary
> > (1) First of all, let's remind that RFC7252 does not define how CoAP
> ping must
> > be used. It does only say:
> >
> > ==
> >       Provoking a Reset
> > How the liveness is assessed is left to applications. So, there is ** no
> layer
> > violation **.
> >
> liveness
> criteria in
> > As an editor, I don't think a change is needed but I'd like to hear from
> Ben,
> > chairs, and the WG.
> >

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 20 Jul 2019 05:25:53 +0300

Hi Tiru,

thank you for clarification regarding TCP. It seems the this clarification somehow escaped from the
discussion with Mirja (at least I cannot recall it was mentioned).

Regards,
Valery.

> Hi Valery,
> 
> The message transmission parameters including missing-hb-allowed is only for
> UDP transport (not for TCP). For the UDP, she is suggesting us to go with a
> mechanism that checks both side of the connectivity using non-confirmable
> message with ping and pong at the application layer instead of relying on the
> CoAP ping/pong.
> 
> Cheers,
> -Tiru
> 
> > I believe Mirja's main point was that if you use liveness check
> > mechanism in the transport layer, then if it reports that liveness
> > check fails, then it _also_ closes the transport session.
> >
> > Quotes from her emails:
> > "Yes, as Coap Ping is used, the agent should not only conclude that
> > the DOTS signal session is disconnected but also the Coap session and
> > not send any further Coap messages anymore."
> >
> > and
> >
> > "Actually to my understanding this will not work. Both TCP heartbeat
> > and Coap Ping are transmitted reliably. If you don’t receive an ack
> > for these transmissions you are not able to send any additional
> > messages and can only close the connection."
> >
> > I'm not familiar with CoAP, but I suspect she's right about TCP - if
> > TCP layer itself doesn't receive ACK for the sent data after several
> > retransmissions, the connection is closed.
> >
> > As far as I understand the current draft allows underlying liveness
> > check to fail and has a parameter to restart this check several times
> > if this happens. It seems that a new transport session will be created
> > in this case (at least if TCP is used). In my reading of the draft
> > this seems not been assumed, it is assumed that the session remains
> > the same. So, I think that main Mirja's concern is that it won't work (at least
> with TCP).
> >
> > I didn't participate in the WG discussion on this, so I don't know
> > what was discussed regarding this issue. If it was discussed and the
> > WG has come to conclusion that this is not an issue, then I believe
> > more text should be added to the draft so, that people like Mirja, who
> > didn't participate in the discussion, don't have any concerns while reading
> the draft.
> >
> > Regards,
> > Valery.
> >
> >
> >
> >
> > > discussed in this message.
> > >
> > > * Pending Point:
> > >
> > > > in layers is a good approach. But more importantly, you end up
> > > > with un-frequent messages which may still terminate the connection
> > > > at some point, while what you want is to simply send messages
> > > ping must be used. It does only say:
> > >
> > > ==
> > >       Provoking a Reset
> > >  - Taking into account DDoS traffic conditions, a check to assess
> > > the liveness of the peer DOTS agent + maintain NAT/FW state on
> > > on-path
> > devices.
> > >

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 20 Jul 2019 23:05:20 -0500

Hi Valery,

> for the sent data after several retransmissions, the connection is closed.

Thanks for this crisp summary (and thanks Med for the detailed writeup as
well)!

> work (at least with TCP).

My sense is similar; if I could attempt to summarize Mirja's stance, it's
that we're invoking a transport-level feature that does its own retransmit
and backoff, but then if the transport comes back and says "the peer is
gone", we say "but we're under attack, so I don't believe you; try again".
This kicks of another independent set of "retransmits" (I know it's not
technically the right word) with a fresh exponential backoff.  There's two
complaints about this: (1) we're changing the transport, since if the
transport concludes the peer is gone then the transport "normally" tears down
the connection (*) entirely, and (2) the assembly of (exponential backoff
1), (exponential backoff 2), (exponential backoff 2) is strange pacing, and
might be better served by a similar number of "retransmits" but with
different pacing, since the long delay at the end of each backoff period is
not expected to add a huge amount of value in terms of letting congestion
ease during attack time, and we would be just as well served by capping the
delay between retransmits and having more retransmits.

The asterisk on (1) is of course because, as is noted later in the thread,
only TCP tears down the association when it concludes the peer is gone
(assuming I'm reading the right parts of 7252).  Quoting 7252:

                                                        If the
   retransmission counter reaches MAX_RETRANSMIT on a timeout, or if the
   endpoint receives a Reset message, then the attempt to transmit the
   message is canceled and the application process informed of failure.
   On the other hand, if the endpoint receives an acknowledgement in
   time, transmission is considered successful.

So all CoAP does is to tell the application "that request didn't work", but
CoAP is happy to try additional requests on the connection; the teardown
logic is indeed left up to the application.

I'm not sure that we've seen much discussion about (2), though (sorry if I
missed it) -- why is the repeated backoff-and-restart the right pacing for
this purpose?

-Ben

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sun, 21 Jul 2019 06:52:18 +0000

Hi Ben,

There seems to several confusions regarding the heartbeat mechanism, I will try to address all the comments/Discuss from you, Mirja and Valery below:

[1] https://tools.ietf.org/html/rfc7252 is specific to UDP transport (and does not deal with TCP). Please see the first paragraph in https://tools.ietf.org/html/rfc7252#section-3. The message transmission parameters (max-retransmit, ack-timeout and ack-random-factor) and missing-hb-allowed discussed in DOTS signal channel are specific to UDP transport.

[2] CoAP over TCP is discussed in https://tools.ietf.org/html/rfc8323. Please see the following differences b/w CoAP-over UDP and CoAP-over-TCP relevant to our discussion:

a) CoAP ping/pong defined in RFC7252 (uses Empty confirmable message and reset) will not work for CoAP-over-TCP. As per https://tools.ietf.org/html/rfc8323#section-3.4, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient. CoAP-over-TCP defines its own CoAP ping/pong for connection health (see https://tools.ietf.org/html/rfc8323#section-5.4).  

b)Confirmable  and Non-confirmable message types are specific to UDP, and are not supported in CoAP-over-TCP.

[3] For TCP, if no ack is received for CoAP ping for specific duration, TCP will close the connection, and the DOTS client will have to re-establish the TCP connection. missing-hb-allowed is of no use for TCP. We are all in the same page for TCP, and the draft can probably 
      be updated for better clarity.

[4] Now coming to UDP, please see my responses below:

a) As you already know, DOTS signal channel uses heartbeat exchange in both directions, and hence CoAP ping is sent by both DOTS client and server.
b) CoAP ping is a confirmable message and hence the exponential back-off with the default value of MAX_RETRANSMIT is 4 (https://tools.ietf.org/html/rfc7252#section-4.8).
c) CoAP ping is the only confirmable message exchanged during attack (all other messages exchanged during an attack are non-confirmable).  The specification allows distinct values for message transmission parameters and missing-hb-allowed to be used during attack and peace times.

To handle congestion conditions during an attack, the specification allows two options:

[Option a] By setting MAX_RETRANSMIT to 1, exponential-back off is avoided and missing-hb-allowed set to a very higher value (e.g. 20) to handle congestion (high packet loss). The draft can be updated to explain [Option a] in more detail.
[Option b] The CoAP MAX_RETRANSMIT default value of 4 is not modified, and for example, missing-hb-allowed can be set to 5 (since 4 transmits are not sufficient to detect the peer is not alive during congestion). 

The Discuss from Mirja is not to rely on the CoAP ping/pong but to define it in the DOTS layer itself (please see https://mailarchive.ietf.org/arch/msg/dots/V6vv28zDpdY5eR_kaB7L-60bhkk) and suggested to go with an alternate design using non-confirmable messages. The alternate design won't work is our assessment, please see my response https://mailarchive.ietf.org/arch/msg/dots/QRMfsmhPTFksN6a_nBBKimVx-lM 

Cheers,
-Tiru

> From: Dots <[email-masked]> On Behalf Of Benjamin Kaduk
> Sent: Sunday, July 21, 2019 9:35 AM
> To: Valery Smyslov <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Hi Valery,
> 
> > mechanism in the transport layer, then if it reports that liveness check fails,
> then it _also_ closes the transport session.
> >
> > Quotes from her emails:
> > "Yes, as Coap Ping is used, the agent should not only conclude that the
> DOTS signal session is disconnected but also the Coap session and not send
> any further Coap messages anymore."
> >
> > and
> >
> > this seems not been assumed, it is assumed that the session remains the
> same. So, I think that main Mirja's concern is that it won't work (at least with
> TCP).
> 
> My sense is similar; if I could attempt to summarize Mirja's stance, it's that
> we're invoking a transport-level feature that does its own retransmit and
> backoff, but then if the transport comes back and says "the peer is gone", we
> say "but we're under attack, so I don't believe you; try again".
> complaints about this: (1) we're changing the transport, since if the transport
> concludes the peer is gone then the transport "normally" tears down the
> connection (*) entirely, and (2) the assembly of (exponential backoff 1),
> (exponential backoff 2), (exponential backoff 2) is strange pacing, and might
> be better served by a similar number of "retransmits" but with different
> pacing, since the long delay at the end of each backoff period is not expected
> to add a huge amount of value in terms of letting congestion ease during
> attack time, and we would be just as well served by capping the delay
> between retransmits and having more retransmits.
> 
> The asterisk on (1) is of course because, as is noted later in the thread, only
> TCP tears down the association when it concludes the peer is gone (assuming
> I'm reading the right parts of 7252).  Quoting 7252:
> 
>                                                         If the
> So all CoAP does is to tell the application "that request didn't work", but CoAP
> is happy to try additional requests on the connection; the teardown logic is
> indeed left up to the application.
> 
> missed it) -- why is the repeated backoff-and-restart the right pacing for this
> purpose?
> 
> -Ben
> 
> didn't participate in the discussion, don't have any concerns while reading the
> draft.
> >
> > Regards,
> > Valery.
> >
> >
> >
> >
> > > the liveness of the peer DOTS agent + maintain NAT/FW state on on-path
> devices.
> > >

---

From: <[email-masked]>
Date: Mon, 22 Jul 2019 07:08:19 +0000

Hi Valery,

Actually, we have clarified that (see for example, https://mailarchive.ietf.org/arch/msg/dots/21wgxXEy-vWecFZK9BeviBFMdnA) 

> All the message transmission parameters including missing-hb-
> allowed are configurable using the DOTS signal channel (see draft-ietf-
> dots-signal-channel-35#section-4.5) and these message transmission
> parameter including the missing-hb-allowed is only used for UDP transport.

We can add this NEW text to Section 4.5 If this would help:

   When the DOTS signal channel is established over a reliable transport
   (e.g., TCP), there is no need for the reliability mechanisms provided
   by CoAP over UDP since the underlying TCP connection provides
   retransmissions and deduplication [RFC8323].  As such, the
   transmission-related parameters (missing-hb-allowed and acceptable
   signal loss ratio) are negotiated only for DOTS over unreliable
   transports.

Cheers,
Med

> De : Valery Smyslov [mailto:[email-masked]]
> Envoyé : samedi 20 juillet 2019 04:26
> À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed TGI/OLN; 'Benjamin
> Kaduk'; [email-masked]; [email-masked]
> Objet : RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> 
> Hi Tiru,
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 22 Jul 2019 08:57:36 +0000

> Sent: Monday, July 22, 2019 12:38 PM
> To: Valery Smyslov <[email-masked]>; Konda, Tirumaleswar Reddy
> <[email-masked]>; 'Benjamin Kaduk'
> <[email-masked]>; [email-masked]; [email-masked]
> Subject: RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> 
> Actually, we have clarified that (see for example,
> https://mailarchive.ietf.org/arch/msg/dots/21wgxXEy-
> vWecFZK9BeviBFMdnA)
> 
> > All the message transmission parameters including missing-hb- allowed
> > are configurable using the DOTS signal channel (see draft-ietf-

I propose to slightly modify the text as follows:

    When the DOTS signal channel is established over a reliable transport
    (e.g., TCP), there is no need for the reliability mechanisms provided
    by CoAP over UDP since the underlying TCP connection provides
    retransmissions and deduplication [RFC8323].  As a reminder, Confirmable  and Non-confirmable message types are specific to unreliable transport, and 
    are not supported in CoAP over TCP.  As such, the message
    transmission-related parameters (missing heartbeats allowed and acceptable
    signal loss ratio) are negotiated only for DOTS over unreliable
    transports. If the CoAP ping us unacknowledged for a specific duration (i.e. TCP user timeout expires), TCP will forcefully close the connection, and the DOTS client will have 
     to re-establish the TCP connection.

Cheers,
-Tiru

> > De : Valery Smyslov [mailto:[email-masked]] Envoyé : samedi 20
> > juillet 2019 04:26 À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed
> > TGI/OLN; 'Benjamin Kaduk'; [email-masked]; [email-masked] Objet :
> > RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> >
> > Hi Tiru,
> >
> > thank you for clarification regarding TCP. It seems the this
> > clarification somehow escaped from the discussion with Mirja (at least
> > I cannot recall it was mentioned).
> >
> > Regards,
> > Valery.
> >
> > > Hi Valery,
> > >
> > > The message transmission parameters including missing-hb-allowed is
> > > only
> > for
> > > message with ping and pong at the application layer instead of
> > > relying
> > on the
> > > CoAP ping/pong.
> > >
> > > Cheers,
> > > -Tiru
> > >
> > > > To: [email-masked]; 'Benjamin Kaduk'
> > > > <[email-masked]>; [email-masked]; [email-masked]
> > > > "Yes, as Coap Ping is used, the agent should not only conclude
> > > > that the DOTS signal session is disconnected but also the Coap
> > > > session and not send any further Coap messages anymore."
> > > >
> > > > and
> > > >
> > > > "Actually to my understanding this will not work. Both TCP
> > > > heartbeat and Coap Ping are transmitted reliably. If you don’t
> > > > receive an ack for these transmissions you are not able to send
> > > > any additional messages and can only close the connection."
> > > >
> > > > I'm not familiar with CoAP, but I suspect she's right about TCP -
> > > > if TCP layer itself doesn't receive ACK for the sent data after
> > > > several retransmissions, the connection is closed.
> > > >
> > > > As far as I understand the current draft allows underlying
> > > > liveness check to fail and has a parameter to restart this check
> > > > several times if this happens. It seems that a new transport
> > > > session will be created in this case (at least if TCP is used). In
> > > > my reading of the draft this seems not been assumed, it is assumed
> > > > that the session remains the same. So, I think that main Mirja's
> > > > concern is that it won't work
> > (at least
> > > with TCP).
> > > >
> > > > what was discussed regarding this issue. If it was discussed and
> > > > the WG has come to conclusion that this is not an issue, then I
> > > > believe more text should be added to the draft so, that people
> > > > like Mirja, who didn't participate in the discussion, don't have
> > > > any concerns while
> > reading
> > > the draft.
> > > >
> > > > Regards,
> > > > Valery.
> > > >
> > > >
> > > >
> > > >
> > > > > Rather than going into much details, I consider the following as
> > > > > the summary of the remaining DISCUSS point from Mirja:
> > > > >
> > > > > > violation, but if more an idealistic concern but usually
> > > > > > designing in layers is a good approach. But more importantly,
> > > > > > you end up with un-frequent messages which may still terminate
> > > > > > the connection at some point, while what you want is to simply
> > > > > > send messages frequently in an unreliable fashion but a low
> > > > > > rate until the
> > attack is over.
> > > > >
> > > > > * Discussion:
> > > > >
> > > > > (1) First of all, let's remind that RFC7252 does not define how
> > > > > CoAP ping must be used. It does only say:
> > > > >
> > > > > ==
> > > > >       Provoking a Reset
> > > > > How the liveness is assessed is left to applications. So, there
> > > > > is
> > > > > ** no layer violation **.
> > > > >
> > > > > > to simply send messages frequently in an unreliable fashion
> > > > > > but a low rate until the attack is over "
> > > > >
> > > > >  - Taking into account DDoS traffic conditions, a check to
> > > > > assess the liveness of the peer DOTS agent + maintain NAT/FW
> > > > > state on on-path
> > > > devices.
> > > > >
> > > > > - The intended functionality is naturally provided by existing
> > > > > CoAP
> > > > messages.
> > > > > - Informed WG decision: The WG spent a lot of cycles when
> > > > > specifying the current behavior to be meet the requirements set in
> RFC8612.
> > > > > - Why not an alternative design: We can always define messages
> > > > > with duplicated functionality, but that is not a good design
> > > > > approach especially when there is no evident benefit.

---

From: <[email-masked]>
Date: Mon, 22 Jul 2019 09:45:41 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : lundi 22 juillet 2019 10:58
> À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; 'Benjamin Kaduk'; dots-
>     retransmissions and deduplication [RFC8323].  As a reminder,
> Confirmable  and Non-confirmable message types are specific to unreliable
> transport, and

[Med] OK. I went with the following: 

   When the DOTS signal channel is established over a reliable transport
   (e.g., TCP), there is no need for the reliability mechanisms provided
   by CoAP over UDP since the underlying TCP connection provides
   retransmissions and deduplication [RFC8323].  As a reminder, CoAP
   over reliable transports does not support Confirmable or Non-
   confirmable message types.  As such, the transmission-related
   parameters (missing-hb-allowed and acceptable signal loss ratio) are
   negotiated only for DOTS over unreliable transports.

If the CoAP ping us unacknowledged for a specific duration
> (i.e. TCP user timeout expires), TCP will forcefully close the connection,
> and the DOTS client will have

[Med] and made this change:

OLD:
   In DOTS over TCP, heartbeat messages MUST be exchanged between the
   DOTS agents using the Ping and Pong messages specified in Section 5.4
   of [RFC8323].  That is, the DOTS agent sends a Ping message and the
   peer DOTS agent would respond by sending a single Pong message.  

NEW:
   In DOTS over TCP, heartbeat messages MUST be exchanged between the
   DOTS agents using the Ping and Pong messages specified in Section 5.4
   of [RFC8323].  That is, the DOTS agent sends a Ping message and the
   peer DOTS agent would respond by sending a single Pong message.  The
   sender of a Ping message has to allow up to 'heartbeat-interval'
   seconds when waiting for a Pong reply.  When a failure is detected by
   a DOTS client, it proceeds with the session recovery following the
   same approach as the one used for unreliable transports.

Better?

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 22 Jul 2019 10:24:56 +0000

> Sent: Monday, July 22, 2019 3:16 PM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>; Valery Smyslov
> <[email-masked]>; 'Benjamin Kaduk' <[email-masked]>; dots-
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[email-masked]]
> > [email-masked]; [email-masked] Objet : RE: [Dots] Mirja's DISCUSS:
> > Pending Point (AD Help Needed)
> >
> > > open attachments unless you recognize the sender and know the
> > > content is safe.
> > >
> > > Hi Valery,
> > >
> > Confirmable  and Non-confirmable message types are specific to
> > unreliable transport, and

Looks good. 

> > (i.e. TCP user timeout expires), TCP will forcefully close the
> > connection, and the DOTS client will have
>    seconds when waiting for a Pong reply.  

The last line does not look correct, the default heartbeat-interval is 30 seconds and the default user timeout is 5 minutes (TCP connection will be closed only after 5 minutes, see https://tools.ietf.org/html/rfc5482), 30 seconds looks aggressive to 
determine the connection is lost.

Cheers,
-Tiru

>    When a failure is detected by
> > > > juillet 2019 04:26 À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR
> > > > Mohamed TGI/OLN; 'Benjamin Kaduk'; [email-masked];
> [email-masked] Objet :
> > > > clarification somehow escaped from the discussion with Mirja (at
> > > > least I cannot recall it was mentioned).
> > > >
> > > > Regards,
> > > > Valery.
> > > >
> > > > > Hi Valery,
> > > > >
> > > > > The message transmission parameters including missing-hb-allowed
> > > > > is only
> > > > for
> > > > > UDP transport (not for TCP). For the UDP, she is suggesting us
> > > > > to go
> > > > with a
> > > > > > I believe Mirja's main point was that if you use liveness
> > > > > > check mechanism in the transport layer, then if it reports
> > > > > > that liveness check fails, then it _also_ closes the transport session.
> > > > > >
> > > > > > Quotes from her emails:
> > > > > > receive an ack for these transmissions you are not able to
> > > > > > send any additional messages and can only close the connection."
> > > > > >
> > > > > > I'm not familiar with CoAP, but I suspect she's right about
> > > > > > TCP - if TCP layer itself doesn't receive ACK for the sent
> > > > > > data after several retransmissions, the connection is closed.
> > > > > >
> > > > > > liveness check to fail and has a parameter to restart this
> > > > > > check several times if this happens. It seems that a new
> > > > > > transport session will be created in this case (at least if
> > > > > > TCP is used). In my reading of the draft this seems not been
> > > > > > assumed, it is assumed that the session remains the same. So,
> > > > > > I think that main Mirja's concern is that it won't work
> > > > (at least
> > > > > with TCP).
> > > > > >
> > > > > > I didn't participate in the WG discussion on this, so I don't
> > > > > > know what was discussed regarding this issue. If it was
> > > > > > discussed and the WG has come to conclusion that this is not
> > > > > > an issue, then I believe more text should be added to the
> > > > > > draft so, that people like Mirja, who didn't participate in
> > > > > > the discussion, don't have any concerns while
> > > > reading
> > > > > the draft.
> > > > > >
> > > > > > Regards,
> > > > > > Valery.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > Rather than going into much details, I consider the
> > > > > > > following as the summary of the remaining DISCUSS point from
> Mirja:
> > > > > > >
> > > > > > > > I believe there are flaws in the design. First it’s a
> > > > > > > > layer violation, but if more an idealistic concern but
> > > > > > > > usually designing in layers is a good approach. But more
> > > > > > > > importantly, you end up with un-frequent messages which
> > > > > > > > may still terminate the connection at some point, while
> > > > > > > > what you want is to simply send messages frequently in an
> > > > > > > > unreliable fashion but a low rate until the
> > > > attack is over.
> > > > > > >
> > > > > > > * Discussion:
> > > > > > >
> > > > > > > (1) First of all, let's remind that RFC7252 does not define
> > > > > > > how CoAP ping must be used. It does only say:
> > > > > > >
> > > > > > > ==
> > > > > > >       Provoking a Reset
> > > > > > >       message (e.g., by sending an Empty Confirmable
> > > > > > > message) is
> > > > also
> > > > > > > How the liveness is assessed is left to applications. So,
> > > > > > > there is
> > > > > > > > to simply send messages frequently in an unreliable
> > > > > > > > fashion but a low rate until the attack is over "
> > > > > > >
> > > > > > > An much more elaborated version is documented in SIG-004 of
> > > > > > > RFC
> > > > 8612.
> > > > > > >
> > > > > > > * My analysis:
> > > > > > >
> > > > > > > - The intended functionality is naturally provided by
> > > > > > > existing CoAP
> > > > > > messages.
> > > > > > > specifying the current behavior to be meet the requirements
> > > > > > > set
> > in
> > > RFC8612.
> > > > > > > - Why not an alternative design: We can always define
> > > > > > > messages with duplicated functionality, but that is not a
> > > > > > > good design approach especially when there is no evident benefit.
> > > > > > > https://www.ietf.org/blog/discuss-criteria-iesg-review/#stan
> > > > > > > d-
> > > > > > undisc.
> > > > > > >
> > > > > > > * What's Next?
> > > > > > >

---

From: <[email-masked]>
Date: Mon, 22 Jul 2019 11:01:35 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : lundi 22 juillet 2019 12:25
> The last line does not look correct, the default heartbeat-interval is 30
> seconds and the default user timeout is 5 minutes (TCP connection will be
> closed only after 5 minutes, see https://tools.ietf.org/html/rfc5482), 30
> seconds looks aggressive to

[Med] This is a configurable parameter. When TCP is used, the server will return the appropriate value to use.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 22 Jul 2019 13:27:08 +0000

> Sent: Monday, July 22, 2019 4:32 PM
> > > > Envoyé : lundi 22 juillet 2019 10:58 À : BOUCADAIR Mohamed
> > > > TGI/OLN; Valery Smyslov; 'Benjamin Kaduk';
> > > dots-
> > > > > To: Valery Smyslov <[email-masked]>; Konda, Tirumaleswar
> > > > > Reddy <[email-masked]>; 'Benjamin
> Kaduk'
> > > > > This email originated from outside of the organization. Do not
> > > > > click
> > > > links or
> > > > > > dots-signal-channel-35#section-4.5) and these message
> > > > > > transmission parameter including the missing-hb-allowed is
> > > > > > only used for UDP
> > > > transport.
> > > > >
> > The last line does not look correct, the default heartbeat-interval is
> > 30 seconds and the default user timeout is 5 minutes (TCP connection
> > will be closed only after 5 minutes, see
> > https://tools.ietf.org/html/rfc5482), 30 seconds looks aggressive to

Yes, but 30 seconds of timeout looks too aggressive. I suggest we use 2 minutes (UDP uses 105 seconds) of heartbeat-interval.

Cheers,
-Tiru

> > > > > > De : Valery Smyslov [mailto:[email-masked]] Envoyé :
> > > > > > samedi 20 juillet 2019 04:26 À : 'Konda, Tirumaleswar Reddy';
> > > > > > BOUCADAIR Mohamed TGI/OLN; 'Benjamin Kaduk';
> > > > > > [email-masked];
> > > [email-masked] Objet :
> > > > > > clarification somehow escaped from the discussion with Mirja
> > > > > > (at least I cannot recall it was mentioned).
> > > > > >
> > > > > > Regards,
> > > > > > Valery.
> > > > > >
> > > > > > > Hi Valery,
> > > > > > >
> > > > > > > The message transmission parameters including
> > > > > > > missing-hb-allowed is only
> > > > > > for
> > > > > > > UDP transport (not for TCP). For the UDP, she is suggesting
> > > > > > > us to go
> > > > > > with a
> > > > > > > mechanism that checks both side of the connectivity using
> > > > > > > non-
> > > > > > confirmable
> > > > > > > message with ping and pong at the application layer instead
> > > > > > > of relying
> > > > > > on the
> > > > > > > CoAP ping/pong.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > -Tiru
> > > > > > >
> > > > > > > > Subject: Re: [Dots] Mirja's DISCUSS: Pending Point (AD
> > > > > > > > Help
> > > > > > > > Needed)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi Med,
> > > > > > > >
> > > > > > > > that liveness check fails, then it _also_ closes the
> > > > > > > > transport
> > session.
> > > > > > > >
> > > > > > > > Quotes from her emails:
> > > > > > > > "Yes, as Coap Ping is used, the agent should not only
> > > > > > > > conclude that the DOTS signal session is disconnected but
> > > > > > > > also the Coap session and not send any further Coap messages
> anymore."
> > > > > > > >
> > > > > > > > and
> > > > > > > >
> > > > > > > > heartbeat and Coap Ping are transmitted reliably. If you
> > > > > > > > don’t receive an ack for these transmissions you are not
> > > > > > > > able to send any additional messages and can only close
> > > > > > > > the
> > connection."
> > > > > > > >
> > > > > > > > I'm not familiar with CoAP, but I suspect she's right
> > > > > > > > about TCP - if TCP layer itself doesn't receive ACK for
> > > > > > > > the sent data after several retransmissions, the connection is
> closed.
> > > > > > > >
> > > > > > > > transport session will be created in this case (at least
> > > > > > > > if TCP is used). In my reading of the draft this seems not
> > > > > > > > been assumed, it is assumed that the session remains the
> > > > > > > > same. So, I think that main Mirja's concern is that it
> > > > > > > > won't work
> > > > > > (at least
> > > > > > > with TCP).
> > > > > > > >
> > > > > > > > I didn't participate in the WG discussion on this, so I
> > > > > > > > don't know what was discussed regarding this issue. If it
> > > > > > > > was discussed and the WG has come to conclusion that this
> > > > > > > > is not an issue, then I believe more text should be added
> > > > > > > > to the draft so, that people like Mirja, who didn't
> > > > > > > > participate in the discussion, don't have any concerns
> > > > > > > > while
> > > > > > reading
> > > > > > > the draft.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Valery.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > To: Benjamin Kaduk ([email-masked]) <[email-masked]>;
> > > > > > > > > dots- [email-masked]; [email-masked]
> > > > > > > > > All DISCUSS points from Mirja's review were fixed,
> > > > > > > > > except the one discussed in this message.
> > > > > > > > >
> > > > > > > > > * Pending Point:
> > > > > > > > >
> > > > > > > > > > usually designing in layers is a good approach. But
> > > > > > > > > > more importantly, you end up with un-frequent messages
> > > > > > > > > > which may still terminate the connection at some
> > > > > > > > > > point, while what you want is to simply send messages
> > > > > > > > > > frequently in an unreliable fashion but a low rate
> > > > > > > > > > until the
> > > > > > attack is over.
> > > > > > > > >
> > > > > > > > > * Discussion:
> > > > > > > > >
> > > > > > > > > (1) First of all, let's remind that RFC7252 does not
> > > > > > > > > define how CoAP ping must be used. It does only say:
> > > > > > > > >
> > > > > > > > > ==
> > > > > > > > >       Provoking a Reset
> > > > > > > > >       useful as an inexpensive check of the liveness of
> > > > > > > > > an
> > > > endpoint
> > > > > > > > >       ("CoAP ping").
> > > > > > > > > ==
> > > > > > > > >
> > > > > > > > > How the liveness is assessed is left to applications.
> > > > > > > > > So, there is
> > > > > > > > >    servers that might want to reduce heartbeat frequency
> > > > > > > > > or
> > > > cease
> > > > > > > > >    heartbeat exchanges when an active DOTS client has
> > > > > > > > > not
> > > > requested
> > > > > > > > >    mitigation."
> > > > > > > > >
> > > > > > > > >  - Taking into account DDoS traffic conditions, a check
> > > > > > > > > to assess the liveness of the peer DOTS agent + maintain
> > > > > > > > > NAT/FW state on on-path
> > > > > > > > devices.
> > > > > > > > >
> > > > > > > > > An much more elaborated version is documented in SIG-004
> > > > > > > > > of RFC
> > > > > > 8612.
> > > > > > > > >
> > > > > > > > > * My analysis:
> > > > > > > > >
> > > > > > > > > - Informed WG decision: The WG spent a lot of cycles
> > > > > > > > > when specifying the current behavior to be meet the
> > > > > > > > > requirements set
> > > > in
> > > > > RFC8612.
> > > > > > > > > messages with duplicated functionality, but that is not
> > > > > > > > > a good design approach especially when there is no
> > > > > > > > > evident
> > benefit.
> > > > > > > > > - The specification is not broken: it was implemented
> > > > > > > > > and
> > > > tested.
> > > > > > > > >
> > > > > > > > > As an editor, I don't think a change is needed but I'd
> > > > > > > > > like to hear from Ben, chairs, and the WG.
> > > > > > > > >

---

From: <[email-masked]>
Date: Mon, 22 Jul 2019 13:39:05 +0000

Re-,

> Yes, but 30 seconds of timeout looks too aggressive. I suggest we use 2
> minutes (UDP uses 105 seconds) of heartbeat-interval.

30 seconds is recommended value for UDP (as this is our favorite transport).

If TCP is used, this falls into the following: 

      DOTS agents may
      negotiate longer heartbeat-interval values to prevent any network
      overload with too frequent keepalives.

Even if we include another recommended value for TCP, I'm afraid it is not possible to reflect this in the YANG module: 

         leaf current-value {
           type uint16;
           units "seconds";
           default "30";
           description
             "Current heartbeat-interval value.

              '0' means that heartbeat mechanism is deactivated.";
         }

Cheers,
Med

> Envoyé : lundi 22 juillet 2019 15:27
> The
> > [Med] This is a configurable parameter. When TCP is used, the server
> will
> > return the appropriate value to use.
> 
> Yes, but 30 seconds of timeout looks too aggressive. I suggest we use 2
> minutes (UDP uses 105 seconds) of heartbeat-interval.
> 
> Cheers,
> -Tiru
> 
> >
> > > Cheers,
> > > -Tiru
> > >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 22 Jul 2019 14:02:18 +0000

> Sent: Monday, July 22, 2019 7:09 PM
> > Yes, but 30 seconds of timeout looks too aggressive. I suggest we use
> > 2 minutes (UDP uses 105 seconds) of heartbeat-interval.
> 

I meant use 2 minutes for TCP (UDP heartbeat interval is 30 seconds, and the timeout happens after 105 seconds). 

>       overload with too frequent keepalives.

The above line is deployment specific not transport specific.

> 
> Even if we include another recommended value for TCP, I'm afraid it is not
> possible to reflect this in the YANG module:
> 
>          leaf current-value {
>            type uint16;
>            units "seconds";
>            default "30";
>            description

Yes, it is YANG limitation but not stop the protocol from giving a recommendation for TCP.

Cheers,
-Tiru

> > > > Envoyé : lundi 22 juillet 2019 12:25 À : BOUCADAIR Mohamed
> > > > > > > This email originated from outside of the organization. Do
> > > > > > > not click
> > > > > > links or
> > > > > > > open attachments unless you recognize the sender and know
> > > > > > > the content is safe.
> > > > > > >
> > > > > > > Hi Valery,
> > > > > > >
> > > > > > > > All the message transmission parameters including
> > > > > > > > missing-hb- allowed are configurable using the DOTS signal
> > > > > > > > channel (see
> > > > > > > > draft-ietf-
> > > > > > >    When the DOTS signal channel is established over a
> > > > > > > reliable
> > > > transport
> > > > > > >    (e.g., TCP), there is no need for the reliability
> > > > > > > mechanisms
> > > > provided
> > > > > >     When the DOTS signal channel is established over a
> > > > > > reliable
> > > > transport
> > > > > >     (e.g., TCP), there is no need for the reliability
> > > > > > mechanisms
> > > > provided
> > > > > >     retransmissions and deduplication [RFC8323].  As a
> > > > > > reminder, Confirmable  and Non-confirmable message types are
> > > > > > specific to unreliable transport, and
> > > > >    parameters (missing-hb-allowed and acceptable signal loss
> > > > > ratio)
> > are
> > > > >    In DOTS over TCP, heartbeat messages MUST be exchanged
> > > > > between
> > > the
> > > > >    DOTS agents using the Ping and Pong messages specified in
> > > > > Section
> > 5.4
> > > > >    of [RFC8323].  That is, the DOTS agent sends a Ping message
> > > > > and
> > the
> > > > >    In DOTS over TCP, heartbeat messages MUST be exchanged
> > > > > between
> > > the
> > > > >    DOTS agents using the Ping and Pong messages specified in
> > > > > Section
> > 5.4
> > > > >    of [RFC8323].  That is, the DOTS agent sends a Ping message
> > > > > and
> > the
> > > > 30 seconds and the default user timeout is 5 minutes (TCP
> > > > connection will be closed only after 5 minutes, see
> > > > https://tools.ietf.org/html/rfc5482), 30 seconds looks aggressive
> > > > to determine the connection is lost.
> > > >
> > >
> > Yes, but 30 seconds of timeout looks too aggressive. I suggest we use
> > 2 minutes (UDP uses 105 seconds) of heartbeat-interval.
> >
> > Cheers,
> > -Tiru
> >
> > >
> > > > Cheers,
> > > > -Tiru
> > > >
> > > > >    a DOTS client, it proceeds with the session recovery
> > > > > following
> > the
> > > > > > > > -----Message d'origine----- De : Valery Smyslov
> > > > > > > > [mailto:[email-masked]] Envoyé :
> > > > > > > > samedi 20 juillet 2019 04:26 À : 'Konda, Tirumaleswar
> > > > > > > > Reddy'; BOUCADAIR Mohamed TGI/OLN; 'Benjamin Kaduk';
> > > > > > > > [email-masked];
> > > > > [email-masked] Objet :
> > > > > > > > thank you for clarification regarding TCP. It seems the
> > > > > > > > this clarification somehow escaped from the discussion
> > > > > > > > with Mirja (at least I cannot recall it was mentioned).
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Valery.
> > > > > > > >
> > > > > > > > > Hi Valery,
> > > > > > > > >
> > > > > > > > > UDP transport (not for TCP). For the UDP, she is
> > > > > > > > > suggesting us to go
> > > > > > > > with a
> > > > > > > > > message with ping and pong at the application layer
> > > > > > > > > instead of relying
> > > > > > > > on the
> > > > > > > > > CoAP ping/pong.
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > > -Tiru
> > > > > > > > >
> > > > > > > > > > I believe Mirja's main point was that if you use
> > > > > > > > > > liveness check mechanism in the transport layer, then
> > > > > > > > > > if it reports that liveness check fails, then it
> > > > > > > > > > _also_ closes the transport
> > > > session.
> > > > > > > > > >
> > > > > > > > > > Quotes from her emails:
> > > > > > > > > > conclude that the DOTS signal session is disconnected
> > > > > > > > > > but also the Coap session and not send any further
> > > > > > > > > > Coap
> > messages
> > > anymore."
> > > > > > > > > >
> > > > > > > > > > and
> > > > > > > > > >
> > > > > > > > > > "Actually to my understanding this will not work. Both
> > > > > > > > > > TCP heartbeat and Coap Ping are transmitted reliably.
> > > > > > > > > > If you don’t receive an ack for these transmissions
> > > > > > > > > > you are not able to send any additional messages and
> > > > > > > > > > can only close the
> > > > connection."
> > > > > > > > > >
> > > > > > > > > > about TCP - if TCP layer itself doesn't receive ACK
> > > > > > > > > > for the sent data after several retransmissions, the
> > connection is
> > > closed.
> > > > > > > > > >
> > > > > > > > > > As far as I understand the current draft allows
> > > > > > > > > > underlying liveness check to fail and has a parameter
> > > > > > > > > > to restart this check several times if this happens.
> > > > > > > > > > It seems that a new transport session will be created
> > > > > > > > > > in this case (at least if TCP is used). In my reading
> > > > > > > > > > of the draft this seems not been assumed, it is
> > > > > > > > > > assumed that the session remains the same. So, I think
> > > > > > > > > > that main Mirja's concern is that it won't work
> > > > > > > > (at least
> > > > > > > > > with TCP).
> > > > > > > > > >
> > > > > > > > > > I didn't participate in the WG discussion on this, so
> > > > > > > > > > I don't know what was discussed regarding this issue.
> > > > > > > > > > If it was discussed and the WG has come to conclusion
> > > > > > > > > > that this is not an issue, then I believe more text
> > > > > > > > > > should be added to the draft so, that people like
> > > > > > > > > > Mirja, who didn't participate in the discussion, don't
> > > > > > > > > > have any concerns while
> > > > > > > > reading
> > > > > > > > > the draft.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > Valery.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > I believe there are flaws in the design. First
> > > > > > > > > > > > it’s a layer violation, but if more an idealistic
> > > > > > > > > > > > concern but usually designing in layers is a good
> > > > > > > > > > > > approach. But more importantly, you end up with
> > > > > > > > > > > > un-frequent messages which may still terminate the
> > > > > > > > > > > > connection at some point, while what you want is
> > > > > > > > > > > > to simply send messages frequently in an
> > > > > > > > > > >       useful as an inexpensive check of the liveness
> > > > > > > > > > > of an
> > > > > > endpoint
> > > > > > > > > > >       ("CoAP ping").
> > > > > > > > > > > ==
> > > > > > > > > > >
> > > > > > > > > > > > to simply send messages frequently in an
> > > > > > > > > > > > unreliable fashion but a low rate until the attack is over "
> > > > > > > > > > >
> > > > > > > > > > >    servers that might want to reduce heartbeat
> > > > > > > > > > > frequency or
> > > > > > cease
> > > > > > > > > > >    heartbeat exchanges when an active DOTS client
> > > > > > > > > > > has not
> > > > > > requested
> > > > > > > > > > >    mitigation."
> > > > > > > > > > >
> > > > > > > > > > >  - Taking into account DDoS traffic conditions, a
> > > > > > > > > > > check to assess the liveness of the peer DOTS agent
> > > > > > > > > > > + maintain NAT/FW state on on-path
> > > > > > > > > > devices.
> > > > > > > > > > >
> > > > > > > > > > > An much more elaborated version is documented in
> > > > > > > > > > > SIG-004 of RFC
> > > > > > > > 8612.
> > > > > > > > > > >
> > > > > > > > > > > * My analysis:
> > > > > > > > > > >
> > > > > > > > > > > - The intended functionality is naturally provided
> > > > > > > > > > > by existing CoAP
> > > > > > > > > > messages.
> > > > > > > > > > > - Why not an alternative design: We can always
> > > > > > > > > > > define messages with duplicated functionality, but
> > > > > > > > > > > that is not a good design approach especially when
> > > > > > > > > > > there is no evident
> > > > benefit.
> > > > > > > > > > > - The specification is not broken: it was
> > > > > > > > > > > implemented and
> > > > > > tested.
> > > > > > > > > > >
> > > > > > > > > > > https://www.ietf.org/blog/discuss-criteria-iesg-revi
> > > > > > > > > > > ew/#
> > > > > > > > > > > stan
> > > > > > > > > > > d-
> > > > > > > > > > undisc.
> > > > > > > > > > >
> > > > > > > > > > > * What's Next?
> > > > > > > > > > >
> > > > > > > > > > > As an editor, I don't think a change is needed but
> > > > > > > > > > > I'd like to hear from Ben, chairs, and the WG.
> > > > > > > > > > >

---

From: <[email-masked]>
Date: Mon, 22 Jul 2019 15:03:21 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : lundi 22 juillet 2019 16:02

[Med] The reco we have for UDP was driven by NAT considerations. For TCP, why using 2 minutes is better than 5 minutes and so on? I'm afraid we don't have such argument. This is why I prefer to leave this deployment-specific. Please remember that using TCP as transport is not the recommended one. 

> The above line is deployment specific not transport specific.

[Med] Deployment considerations cover transport ones.  

> Yes, it is YANG limitation but not stop the protocol from giving a

[Med] The issue is that we need to be consistent: the parameter applies for all transport. We cannot set two defaults for it.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 22 Jul 2019 15:13:29 +0000

Got it, Thanks for the clarifications.

Cheers,
-Tiru

> Sent: Monday, July 22, 2019 8:33 PM
> > I meant use 2 minutes for TCP (UDP heartbeat interval is 30 seconds,
> > and the timeout happens after 105 seconds).
> >
> 
> [Med] The reco we have for UDP was driven by NAT considerations. For TCP,
> why using 2 minutes is better than 5 minutes and so on? I'm afraid we don't
> have such argument. This is why I prefer to leave this deployment-specific.
> Please remember that using TCP as transport is not the recommended one.
> 
> > >
> > > Even if we include another recommended value for TCP, I'm afraid it
> > > is
> > not
> [Med] The issue is that we need to be consistent: the parameter applies for
> all transport. We cannot set two defaults for it.
> 
> >
> > Cheers,
> > -Tiru
> >
> > >
> > > Cheers,
> > > Med
> > >
> > > > Envoyé : lundi 22 juillet 2019 15:27 À : BOUCADAIR Mohamed
> > > > > > > <[email-masked]>; 'Benjamin Kaduk' <[email-masked]>;
> > > > > > > > -----Message d'origine----- De : Konda, Tirumaleswar Reddy
> <[email-masked]>;
> > > > > > > > > 'Benjamin
> > > > > Kaduk'
> > > > > > > > > Subject: RE: [Dots] Mirja's DISCUSS: Pending Point (AD
> > > > > > > > > Help
> > > > > > > > > Needed)
> > > > > > > > >
> > > > > > > > > This email originated from outside of the organization.
> > > > > > > > > Do not click
> > > > > > > > links or
> > > > > > > > > open attachments unless you recognize the sender and
> > > > > > > > > know the content is safe.
> > > > > > > > >
> > > > > > > > > Hi Valery,
> > > > > > > > >
> > > > > > > > > > missing-hb- allowed are configurable using the DOTS
> > > > > > > > > > signal channel (see
> > > > > > > > > > draft-ietf-
> > > > > > > > > > transmission parameter including the
> > > > > > > > > > missing-hb-allowed is only used for UDP
> > > > > > > > transport.
> > > > > > > > >
> > > > > > > > >    retransmissions and deduplication [RFC8323].  As
> > > > > > > > > such,
> > the
> > > > > > > > >    transmission-related parameters (missing-hb-allowed
> > > > > > > > > and
> > > > > > acceptable
> > > > > > > > reminder, Confirmable  and Non-confirmable message types
> > > > > > > > are specific to unreliable transport, and
> > > > > > > reminder,
> > > > > > > > (i.e. TCP user timeout expires), TCP will forcefully close
> > > > > > > > the connection, and the DOTS client will have
> > > > > > >    of [RFC8323].  That is, the DOTS agent sends a Ping
> > > > > > > message and
> > > > the
> > > > > > >    of [RFC8323].  That is, the DOTS agent sends a Ping
> > > > > > > message and
> > > > the
> > > > > > https://tools.ietf.org/html/rfc5482), 30 seconds looks
> > > > > > aggressive to determine the connection is lost.
> > > > > >
> > > > >
> > > > > > > > > > thank you for clarification regarding TCP. It seems
> > > > > > > > > > the this clarification somehow escaped from the
> > > > > > > > > > > > Valery Smyslov
> > > > > > > > > > > > Subject: Re: [Dots] Mirja's DISCUSS: Pending Point
> > > > > > > > > > > > (AD Help
> > > > > > > > > > > > Needed)
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Med,
> > > > > > > > > > > >
> > > > > > > > > > > > liveness check mechanism in the transport layer,
> > > > > > > > > > > > then if it reports that liveness check fails, then
> > > > > > > > > > > > it _also_ closes the transport
> > > > > > session.
> > > > > > > > > > > >
> > > > > > > > > > > > Quotes from her emails:
> > > > > > > > > > > > "Yes, as Coap Ping is used, the agent should not
> > > > > > > > > > > > only conclude that the DOTS signal session is
> > > > > > > > > > > > disconnected but also the Coap session and not
> > > > > > > > > > > > send any further Coap
> > > > messages
> > > > > anymore."
> > > > > > > > > > > >
> > > > > > > > > > > > and
> > > > > > > > > > > >
> > > > > > > > > > > > "Actually to my understanding this will not work.
> > > > > > > > > > > > Both TCP heartbeat and Coap Ping are transmitted
> reliably.
> > > > > > > > > > > > If you don’t receive an ack for these
> > > > > > > > > > > > transmissions you are not able to send any
> > > > > > > > > > > > additional messages and can only close the
> > > > > > connection."
> > > > > > > > > > > >
> > > > > > > > > > > > I'm not familiar with CoAP, but I suspect she's
> > > > > > > > > > > > right about TCP - if TCP layer itself doesn't
> > > > > > > > > > > > receive ACK for the sent data after several
> > > > > > > > > > > > retransmissions, the
> > > > connection is
> > > > > closed.
> > > > > > > > > > > >
> > > > > > > > > > > > underlying liveness check to fail and has a
> > > > > > > > > > > > parameter to restart this check several times if this
> happens.
> > > > > > > > > > > > It seems that a new transport session will be
> > > > > > > > > > > > created in this case (at least if TCP is used). In
> > > > > > > > > > > > my reading of the draft this seems not been
> > > > > > > > > > > > assumed, it is assumed that the session remains
> > > > > > > > > > > > the same. So, I think that main Mirja's concern is
> > > > > > > > > > > > that it won't work
> > > > > > > > > > (at least
> > > > > > > > > > > with TCP).
> > > > > > > > > > > >
> > > > > > > > > > > > I didn't participate in the WG discussion on this,
> > > > > > > > > > > > so I don't know what was discussed regarding this issue.
> > > > > > > > > > > > If it was discussed and the WG has come to
> > > > > > > > > > > > conclusion that this is not an issue, then I
> > > > > > > > > > > > believe more text should be added to the draft so,
> > > > > > > > > > > > that people like Mirja, who didn't participate in
> > > > > > > > > > > > > All DISCUSS points from Mirja's review were
> > > > > > > > > > > > > fixed, except the one discussed in this message.
> > > > > > > > > > > > >
> > > > > > > > > > > > > * Pending Point:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Rather than going into much details, I consider
> > > > > > > > > > > > > the following as the summary of the remaining
> > > > > > > > > > > > > DISCUSS point from
> > > > > > > Mirja:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > it’s a layer violation, but if more an
> > > > > > > > > > > > > > idealistic concern but usually designing in
> > > > > > > > > > > > > > layers is a good approach. But more
> > > > > > > > > > > > > > importantly, you end up with un-frequent
> > > > > > > > > > > > > > messages which may still terminate the
> > > > > > > > > > > > > > connection at some point, while what you want
> > > > > > > > > > > > > > is to simply send messages frequently in an
> > > > > > > > > > > > > (1) First of all, let's remind that RFC7252 does
> > > > > > > > > > > > > not define how CoAP ping must be used. It does only
> say:
> > > > > > > > > > > > >
> > > > > > > > > > > > > ==
> > > > > > > > > > > > >       Provoking a Reset
> > > > > > > > > > > > >       useful as an inexpensive check of the
> > > > > > > > > > > > > liveness of an
> > > > > > > > endpoint
> > > > > > > > > > > > >       ("CoAP ping").
> > > > > > > > > > > > > ==
> > > > > > > > > > > > >
> > > > > > > > > > > > > > attack
> > is over "
> > > > > > > > > > > > >    heartbeat exchanges when an active DOTS
> > > > > > > > > > > > > client has not
> > > > > > > > requested
> > > > > > > > > > > > >    mitigation."
> > > > > > > > > > > > >
> > > > > > > > > > > > >  - Taking into account DDoS traffic conditions,
> > > > > > > > > > > > > a check to assess the liveness of the peer DOTS
> > > > > > > > > > > > > agent
> > > > > > > > > > > > > - The intended functionality is naturally
> > > > > > > > > > > > > provided by existing CoAP
> > > > > > > > > > > > messages.
> > > > > > > > > > > > > - Informed WG decision: The WG spent a lot of
> > > > > > > > > > > > > cycles when specifying the current behavior to
> > > > > > > > > > > > > be meet the requirements set
> > > > > > > > in
> > > > > > > > > RFC8612.
> > > > > > > > > > > > > define messages with duplicated functionality,
> > > > > > > > > > > > > but that is not a good design approach
> > > > > > > > > > > > > As an editor, I don't think a change is needed
> > > > > > > > > > > > > but I'd like to hear from Ben, chairs, and the WG.
> > > > > > > > > > > > >

---

From: <[email-masked]>
Date: Tue, 23 Jul 2019 05:32:26 +0000

Hi Tiru, all,

Please see inline. 

Cheers,
Med

> Envoyé : dimanche 21 juillet 2019 08:52
> À : Benjamin Kaduk; Valery Smyslov
> Cc : [email-masked]; BOUCADAIR Mohamed TGI/OLN; [email-masked]
> There seems to several confusions regarding the heartbeat mechanism, I
> will try to address all the comments/Discuss from you, Mirja and Valery
> below:
> 
> [1] https://tools.ietf.org/html/rfc7252 is specific to UDP transport (and
> does not deal with TCP). Please see the first paragraph in
> https://tools.ietf.org/html/rfc7252#section-3. The message transmission
> parameters (max-retransmit, ack-timeout and ack-random-factor) and
> missing-hb-allowed discussed in DOTS signal channel are specific to UDP
> transport.
> 
> [2] CoAP over TCP is discussed in https://tools.ietf.org/html/rfc8323.
> Please see the following differences b/w CoAP-over UDP and CoAP-over-TCP
> relevant to our discussion:
> 
> a) CoAP ping/pong defined in RFC7252 (uses Empty confirmable message and
> reset) will not work for CoAP-over-TCP. As per
> https://tools.ietf.org/html/rfc8323#section-3.4, Empty messages (Code
> 0.00) can always be sent and MUST be ignored by the recipient. CoAP-over-
> TCP defines its own CoAP ping/pong for connection health (see
> https://tools.ietf.org/html/rfc8323#section-5.4).
> 
> [3] For TCP, if no ack is received for CoAP ping for specific duration,
> TCP will close the connection, and the DOTS client will have to re-
> establish the TCP connection. missing-hb-allowed is of no use for TCP. We
> are all in the same page for TCP, and the draft can probably
> a) As you already know, DOTS signal channel uses heartbeat exchange in
> both directions, and hence CoAP ping is sent by both DOTS client and
> server.
> b) CoAP ping is a confirmable message and hence the exponential back-off
> with the default value of MAX_RETRANSMIT is 4
> (https://tools.ietf.org/html/rfc7252#section-4.8).
> c) CoAP ping is the only confirmable message exchanged during attack (all
> other messages exchanged during an attack are non-confirmable).  The
> specification allows distinct values for message transmission parameters
> and missing-hb-allowed to be used during attack and peace times.
> 
> [Option a] By setting MAX_RETRANSMIT to 1, exponential-back off is avoided
> and missing-hb-allowed set to a very higher value (e.g. 20) to handle
> congestion (high packet loss). The draft can be updated to explain [Option
> a] in more detail.
> [Option b] The CoAP MAX_RETRANSMIT default value of 4 is not modified, and
> for example, missing-hb-allowed can be set to 5 (since 4 transmits are not
> sufficient to detect the peer is not alive during congestion).
> 

[Med] We can add this text to illustrate the configuration flexibility: 

   The specification allows for a flexible retry configuration when an
   unreliable transport is in use.  For example, a server may be tweaked
   to return a lower 'missing-hb-allowed' (e.g., 5) value but delegate
   the retransmission to the underlying CoAP library by setting 'max-
   retransmit' to a high value (e.g., 3).  The server may also be
   configured to return a 'max-retransmit' set to '1' together with a
   higher 'missing-hb-allowed' value (e.g., 15).

> The Discuss from Mirja is not to rely on the CoAP ping/pong but to define
> it in the DOTS layer itself (please see
> https://mailarchive.ietf.org/arch/msg/dots/V6vv28zDpdY5eR_kaB7L-60bhkk)
> and suggested to go with an alternate design using non-confirmable
> messages. The alternate design won't work is our assessment, please see my
> response
> https://mailarchive.ietf.org/arch/msg/dots/QRMfsmhPTFksN6a_nBBKimVx-lM
> 
> Cheers,
> -Tiru
> 
> check fails,

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 23 Jul 2019 06:41:07 +0000

> Sent: Tuesday, July 23, 2019 11:02 AM
> <[email-masked]>; Benjamin Kaduk
> <[email-masked]>; Valery Smyslov <[email-masked]>
> Cc: [email-masked]; [email-masked]
> > Envoyé : dimanche 21 juillet 2019 08:52 À : Benjamin Kaduk; Valery
> > Smyslov Cc : [email-masked]; BOUCADAIR Mohamed TGI/OLN;
> > [email-masked] Objet : RE: [Dots] Mirja's DISCUSS: Pending Point (AD
> > Help Needed)
> >
> > Hi Ben,
> >
> > [1] https://tools.ietf.org/html/rfc7252 is specific to UDP transport
> > (and does not deal with TCP). Please see the first paragraph in
> > https://tools.ietf.org/html/rfc7252#section-3. The message
> > transmission parameters (max-retransmit, ack-timeout and
> > ack-random-factor) and missing-hb-allowed discussed in DOTS signal
> > channel are specific to UDP transport.
> >
> > Please see the following differences b/w CoAP-over UDP and
> > CoAP-over-TCP relevant to our discussion:
> >
> > 0.00) can always be sent and MUST be ignored by the recipient.
> > CoAP-over- TCP defines its own CoAP ping/pong for connection health
> > (see https://tools.ietf.org/html/rfc8323#section-5.4).
> >
> > [3] For TCP, if no ack is received for CoAP ping for specific
> > duration, TCP will close the connection, and the DOTS client will have
> > to re- establish the TCP connection. missing-hb-allowed is of no use
> > for TCP. We are all in the same page for TCP, and the draft can probably
> > b) CoAP ping is a confirmable message and hence the exponential
> > back-off with the default value of MAX_RETRANSMIT is 4
> > c) CoAP ping is the only confirmable message exchanged during attack
> > (all other messages exchanged during an attack are non-confirmable).
> > The specification allows distinct values for message transmission
> > parameters and missing-hb-allowed to be used during attack and peace
> times.
> >
> > [Option a] By setting MAX_RETRANSMIT to 1, exponential-back off is
> > avoided and missing-hb-allowed set to a very higher value (e.g. 20) to
> > handle congestion (high packet loss). The draft can be updated to
> > explain [Option a] in more detail.
> > [Option b] The CoAP MAX_RETRANSMIT default value of 4 is not modified,
> > and for example, missing-hb-allowed can be set to 5 (since 4 transmits
> > are not sufficient to detect the peer is not alive during congestion).
> >
> 

Looks good, Both these techniques are used by protocols today, I see DTLS heartbeat uses retransmit and exponential back-off (see https://tools.ietf.org/html/rfc6347#section-4.2.4.1) for liveness check and in STUN usage for consent freshness (https://tools.ietf.org/html/rfc7675) STUN binding requests are sent periodically. 

Cheers,
-Tiru

> 
> 
> > The Discuss from Mirja is not to rely on the CoAP ping/pong but to
> > define it in the DOTS layer itself (please see
> > https://mailarchive.ietf.org/arch/msg/dots/V6vv28zDpdY5eR_kaB7L-
> 60bhkk
> > ) and suggested to go with an alternate design using non-confirmable
> > messages. The alternate design won't work is our assessment, please
> > see my response
> >
> > > > that
> > > DOTS signal session is disconnected but also the Coap session and
> > > not
> > send
> > > > heartbeat
> > > transmissions you are not able to send any additional messages and
> > > can
> > only
> > > close the connection."
> > > >
> > > > several
> > > Thanks for this crisp summary (and thanks Med for the detailed
> > > writeup
> > as
> > > well)!
> > >
> > > > that the session remains
> > > same. So, I think that main Mirja's concern is that it won't work
> > > (at
> > least with
> > > TCP).
> > >
> > > we're invoking a transport-level feature that does its own
> > > retransmit
> > and
> > > This kicks of another independent set of "retransmits" (I know it's
> > > not technically the right word) with a fresh exponential backoff.
> > > There's
> > two
> > > concludes the peer is gone then the transport "normally" tears down
> > 1),
> > > (exponential backoff 2), (exponential backoff 2) is strange pacing,
> > > and
> > might
> > > be better served by a similar number of "retransmits" but with
> > > different pacing, since the long delay at the end of each backoff
> > > period is not
> > expected
> > > to add a huge amount of value in terms of letting congestion ease
> > > during attack time, and we would be just as well served by capping
> > > the delay between retransmits and having more retransmits.
> > >
> > > So all CoAP does is to tell the application "that request didn't
> > > work",
> > but CoAP
> > > I'm not sure that we've seen much discussion about (2), though
> > > (sorry if
> > I
> > > missed it) -- why is the repeated backoff-and-restart the right
> > > pacing
> > for this
> > > purpose?
> > >
> > > -Ben
> > >
> > > > like Mirja, who
> > > > > state on on-
> > path
> > > > > https://www.ietf.org/blog/discuss-criteria-iesg-
> > review/#stand-
> > > undisc.
> > > > >
> > > > > * What's Next?
> > > > >

---

From: <[email-masked]>
Date: Tue, 23 Jul 2019 13:56:49 +0000

Re-,

Thank you, Tiru,

All: FWIW, we prepared a set of slides to expose the pending DISCUSS point from Mirja. The slides are available at: 
https://datatracker.ietf.org/meeting/105/materials/slides-105-dots-heartbeat-mechanism-mirjas-discuss-on-the-signal-channel-i-d-00 

Cheers,
Med

> Envoyé : mardi 23 juillet 2019 08:41
> À : BOUCADAIR Mohamed TGI/OLN; Benjamin Kaduk; Valery Smyslov
> Cc : [email-masked]; [email-masked]
> Looks good, Both these techniques are used by protocols today, I see DTLS
> heartbeat uses retransmit and exponential back-off (see
> https://tools.ietf.org/html/rfc6347#section-4.2.4.1) for liveness check
> and in STUN usage for consent freshness
> (https://tools.ietf.org/html/rfc7675) STUN binding requests are sent
> periodically.
> 
> Cheers,
> -Tiru
> 
> >
> >

---

From: kaname nishizuka <[email-masked]>
Date: Wed, 24 Jul 2019 03:39:30 +0900

Thank you, Med.

Is the presentation about the signal-channel I-D already included in the agenda?
I can spare at least 5min from `2. Controlling Filtering Rules Using DOTS Signal Channel (15 min)` for this discussion.

thanks,
Kaname

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 24 Jul 2019 08:34:16 -0500

> [Med] The issue is that we need to be consistent: the parameter applies for all transport. We cannot set two defaults for it.  

Sure, but we also can't set two default transports.  We can set a default
value that matches the default (i.e., recommended) transport, and make a
note that when the one parameter is changed, it typically makes sense to
change the other as well.  That's what I thought Tiru was asking for.

-Ben

---

From: <[email-masked]>
Date: Wed, 24 Jul 2019 13:49:40 +0000

Hi Ben, 

IMO, this falls under this text:  

      A heartbeat-interval of 30 seconds may be considered as too chatty
      in some deployments.  For such deployments, DOTS agents may
      negotiate longer heartbeat-interval values to prevent any network
      overload with too frequent keepalives.

Isn't it?

Cheers,
Med

> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : mercredi 24 juillet 2019 15:34
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Konda, Tirumaleswar Reddy; Valery Smyslov; [email-masked];
> [email-masked]
> Objet : Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> 
> > [Med] The issue is that we need to be consistent: the parameter applies
> for all transport. We cannot set two defaults for it.
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 24 Jul 2019 09:01:02 -0500

>       overload with too frequent keepalives.

I think the document is quite clear that there are cases where 30 seconds
doesn't make sense.  My question is whether we want to be very explicit
about linking the "TCP is used" case as being one such case where 30
seconds doesn't make sense.  "No" is a fine answer, but I just wanted to
ask.

-Ben

---

From: <[email-masked]>
Date: Wed, 24 Jul 2019 16:09:31 +0000

Re-,

I don't think so. 

There is already some "generic" text in RFC8323 (CoAP/TCP): 

      "According to
      [HomeGateway], the mean for TCP and UDP NAT binding timeouts is
      386 minutes (TCP) and 160 seconds (UDP).  Shorter timeout values
      require keepalive messages to be sent more frequently.  Hence, the
      use of CoAP over TCP requires less-frequent transmission of
      keepalive messages."

Cheers,
Med

> Envoyé : mercredi 24 juillet 2019 16:01

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 25 Jul 2019 16:01:24 +0300

Hi,

I talked to Mirja yesterday about her DISCUSS and she suggested to ask CoAP expert 
whether the authors do liveness check right from CoAP point of view.
So I asked Carsten to comment on this. I think that Tiru's analysis below
is a good starting point.

Regards,
Valery.

-----Original Message-----
From: Konda, Tirumaleswar Reddy <[email-masked]> 
Sent: Sunday, July 21, 2019 9:52 AM
To: Benjamin Kaduk <[email-masked]>; Valery Smyslov <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)

Hi Ben,

Cheers,
-Tiru

> This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> Hi Valery,
> 
> DOTS signal session is disconnected but also the Coap session and not 
> send any further Coap messages anymore."
> >
> > and
> >
> Coap Ping are transmitted reliably. If you don’t receive an ack for 
> these transmissions you are not able to send any additional messages 
> and can only close the connection."
> >
> Thanks for this crisp summary (and thanks Med for the detailed writeup 
> as well)!
> 
> > check to fail and has a parameter to restart this check several 
> > times if this happens. It seems that a new transport session will be 
> > created in this case (at least if TCP is used). In my reading of the 
> > draft this seems not been assumed, it is assumed that the session 
> > remains the
> same. So, I think that main Mirja's concern is that it won't work (at 
> least with TCP).
> 
> My sense is similar; if I could attempt to summarize Mirja's stance, 
> it's that we're invoking a transport-level feature that does its own 
> retransmit and backoff, but then if the transport comes back and says 
> "the peer is gone", we say "but we're under attack, so I don't believe you; try again".
> There's two complaints about this: (1) we're changing the transport, 
> since if the transport concludes the peer is gone then the transport 
> "normally" tears down the connection (*) entirely, and (2) the 
> assembly of (exponential backoff 1), (exponential backoff 2), 
> (exponential backoff 2) is strange pacing, and might be better served 
> by a similar number of "retransmits" but with different pacing, since 
> the long delay at the end of each backoff period is not expected to 
> add a huge amount of value in terms of letting congestion ease during 
> attack time, and we would be just as well served by capping the delay between retransmits and having more retransmits.
> 
> The asterisk on (1) is of course because, as is noted later in the 
> thread, only TCP tears down the association when it concludes the peer 
> is gone (assuming I'm reading the right parts of 7252).  Quoting 7252:
> 
>                                                         If the
> work", but CoAP is happy to try additional requests on the connection; 
> the teardown logic is indeed left up to the application.
> 
> I'm not sure that we've seen much discussion about (2), though (sorry 
> if I missed it) -- why is the repeated backoff-and-restart the right 
> pacing for this purpose?
> 
> -Ben
> 
> didn't participate in the discussion, don't have any concerns while 
> reading the draft.
> >
> > Regards,
> > Valery.
> >
> >
> >
> >
> > > From: [email-masked] <[email-masked]>
> > > > send messages frequently in an unreliable fashion but a low rate until the attack is over.
> > >
> > > * Discussion:
> > >
> > > > to simply send messages frequently in an unreliable fashion but 
> > > > a low rate until the attack is over "
> > >
> > > specifying the current behavior to be meet the requirements set in RFC8612.