Subject: Re: [Dots] Behavior when keep-alives fail (RE: Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 11 Dec 2019 15:42:25 +0100

Hi Med, hi all,

Just restarting the thread from here but based on the latest version that was submitted (-39). Thanks a lot for the update and the additional work you put in the draft as well as implementation! Really happy to see that you found a solution and that is works!

I think I’m ready to resolve my discuss just two more minor questions on the new wording in the draft. However, I don’t think there are any remaining technical issues and we might just ned to make sure the wording is clear.

Ben pinged me already about this part:
"Mitigation requests MUST NOT be delayed	
 because of other congestion control checks.  Typically, mitigation	
 requests must be sent without checks on probing rate (Section 4.7 of	
 [RFC7252]).”
My understanding right now is that there anyway can only be one active mitigation request at a time…? If that is the case please note this explicitly here because that inherently limits the “rate" at which mitigation request can be sent. However, I also don’t really understand what the two sentences above are meant to say. I looked again at section 4.7 of RFC7257 and am not sure what you are referring to. Can you explain/clarify?

Later on there is this sentence:
“The DOTS client MUST then try to resume the (D)TLS session.”
Does it say anywhere in the document how often/how long it should retry? I think nevertheless we need some kind of termination condition here are retrying to infinity doesn’t seem the “best” approach.

Thanks!
Mirja

> On 17. Jul 2019, at 14:15, [email-masked] wrote:
> 
> Hi Mirja,
> 
> Glad to see that we are progressing. With regards to the remaining issue, let's recap on the intended functionality and general observations.
> 
> * What is the intended functionality?
> 
> (1) What we need is a check to assess the liveness of the peer DOTS agent + maintain NAT/FW state on on-path devices. 
> 
> (2) CoAP does not impose how CoAP Ping messages should be sent, how their response (or lack of) should be interpreted, etc. This is left to the application.
> 
> (3) In a DDoS context, failure to receive heartbeats ** should not ** be systematically interpreted as the session is defunct. To that aim, a specific behavior is followed at the DOTS layer (not CoAP layer). The DOTS layer instructs the CoAP layer (DOTS session, and mitigation operations) accordingly.   
> 
> * Why CoAP Pings?
> 
> CoAP Pings naturally achieve (1). These messages are interesting because they have small message sizes. CoAP Ping uses Empty Confirmable message (no request) and the response is a Reset message (which is empty).
> 
> CoAP Ping can be used ** as-is ** during idle time (no attack). Multiple Ping failures and Ping exchange in both directions is required only during the attack time to really detect if the peer is dead or alive (because of (3)).
> 
> This is aligned with (2).
> 
> * Why not DOTS-specific messages?
> 
> If we have to define such message, it needs to be the smallest footprint as practical. An Empty message is inexpensive, nevertheless empty Non-confirmable messages are not allowed (See rfc7252#section-4.3) and sending the Reset message is optional. 
> 
> Furthermore, if heartbeats were non-confirmable that means that we would need to get the application layer to do any recovery work. It is much simpler to make them confirmable and delegate the recovery work to CoAP layer. 
> 
> So, even if we did it in the DOTS layer it will be the same as "CoAP ping".
> 
> The WG did not see a reason to re-do the same in the application layer. In DOTS, the CoAP ping is initiated by the application (DOTS layer itself) and CoAP layer only handles the retransmissions. The proposed mechanism does not require an update to the CoAP stack other with the assumption that callback handlers are supported to give visibility of when a ping or pong was received by the CoAP layer in the application layer. As such, the current design is pragmatic. 
> 
> The DOTS layer has the ** full control required for the intended functionality **.
> 
> * Why separating heartbeats parameters from CoAP transmission ones?
> 
> We need to allow for a differentiated handling of heartbeats during idle/mitigation times. To that aim, we defined specific heartbeat parameters for each of these times without touching the CoAP connection parameters. 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.
> 
> One last comment about adjusting CoAP parameter values, we spent in the WG a lot of cycles to discuss this particular point. The conclusion of the WG is that 4 retransmits (that corresponds to the default value of MAX_RETRANSMIT) are not sufficient to detect the session is disconnected during volumetric 
> DDoS attack saturating the incoming link, and which will lead to high packet loss. This is why multiple heartbeat losses are required to detect the session is defunct.
> 
> Unless there is a flaw with the current design (fail to achieve the intended functionality, implementation complexity, side effects, ...), we don't see a reason to change the current approach. 
> 
> Thank you. 
> 
> Cheers,
> Jon/Tiru/Med
> 
>> -----Message d'origine-----
>> De : Mirja Kuehlewind [mailto:[email-masked]]
>> Envoyé : mardi 16 juillet 2019 17:41
>> À : Konda, Tirumaleswar Reddy
>> Cc : Jon Shallow; BOUCADAIR Mohamed TGI/OLN; draft-ietf-dots-signal-
>> [email-masked]; [email-masked]; [email-masked]; The IESG;
>> [email-masked]; Benjamin Kaduk
>> Objet : Re: [Dots] Behavior when keep-alives fail (RE: Mirja Kühlewind's
>> Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
>> 
>> Hi Tiru,
>> 
>> Thanks for the updates. I think there is one remaining issue on the use of
>> ping/heart-beats (see also my other message). However, I believe all other
>> discuss points have been addressed now. Thanks for that!
>> 
>> Mirja
>> 
>> 
>

---

From: <[email-masked]>
Date: Thu, 12 Dec 2019 08:12:35 +0000

Hi Mirja,

Thank you for the feedback. 

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 11 décembre 2019 15:42
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [email-masked]; Benjamin Kaduk; dots-
> [email-masked]; [email-masked]; The IESG
> Just restarting the thread from here but based on the latest version that
> was submitted (-39). Thanks a lot for the update and the additional work
> you put in the draft as well as implementation! Really happy to see that
> you found a solution and that is works!
> 
> I think I’m ready to resolve my discuss just two more minor questions on
> the new wording in the draft. However, I don’t think there are any
> remaining technical issues and we might just ned to make sure the wording
> is clear.
> 
> My understanding right now is that there anyway can only be one active
> mitigation request at a time…?

[Med] Exactly. One mitigation request for a mitigation scope is allowed. The authoritative behavior is: 

   DOTS agents MUST NOT send more than one UDP datagram per round-trip
   time (RTT) to the peer DOTS agent

and

   If the DOTS client cannot maintain an RTT estimate, it MUST
   NOT send more than one Non-confirmable request every 3 seconds, and
   SHOULD use an even less aggressive rate whenever possible

The excerpt you quoted is a guard against delaying a mitigation request because, e.g., of a very low probing-rate. We want to make sure that the first mitigation is sent as soon as possible. 

The two guards we have for this are discussed in Slide 8 of https://datatracker.ietf.org/meeting/106/materials/slides-106-dots-dots-signal-channel-heartbeat-mechanism-update-00. 

 If that is the case please note this
> explicitly here because that inherently limits the “rate" at which
> mitigation request can be sent.

[Med] This is mentioned in the sentence right before the one you quoted. 

 However, I also don’t really understand
> what the two sentences above are meant to say. I looked again at section
> 4.7 of RFC7257 and am not sure what you are referring to. Can you
> explain/clarify?

[Med]  As explained above, we are referring to the probing-rate behavior in 4.7 RFC7252:

   The specific algorithm by which a client stops to "expect" a response
   to a Confirmable request that was acknowledged, or to a Non-
   confirmable request, is not defined.  Unless this is modified by
   additional congestion control optimizations, it MUST be chosen in
   such a way that an endpoint does not exceed an average data rate of
   PROBING_RATE in sending to another endpoint that does not respond.

> Does it say anywhere in the document how often/how long it should retry? I
> think nevertheless we need some kind of termination condition here are
> retrying to infinity doesn’t seem the “best” approach.

[Med] This is left to the implementation. Please note that we followed the same approach for when an old session expires (see for example, point #3 in this thread: https://mailarchive.ietf.org/arch/msg/dots/pdiC4xsbQiaazm14hvdTLefcUeY)

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 12 Dec 2019 17:55:33 +0100

Hi Med,

See below.

> On 12. Dec 2019, at 09:12, [email-masked] wrote:
> 
> Hi Mirja,
> 

Great this is all fine. I still think the wording in these sentences is confusing as it says "other congestion control checks”. Given this is already well defined, can we maybe just removed those two sentences (in order to avoid similar confusion as I had for the reader)?

> [Med] This is left to the implementation. Please note that we followed the same approach for when an old session expires (see for example, point #3 in this thread: https://mailarchive.ietf.org/arch…

I was rather talking about the number of retries than an expiration time. E.g. one could say: "The DOTS client SHOULD try to reconnect RECON_NUM times with a default of RECON_NUM=5”
Do you think it would be possible to say anything like that?

Mirja

---

From: <[email-masked]>
Date: Fri, 13 Dec 2019 10:10:34 +0000

Hi Mirja, 

Please see inline.

Cheers,
Med

> Envoyé : jeudi 12 décembre 2019 17:56
> > The excerpt you quoted is a guard against delaying a mitigation request
> because, e.g., of a very low probing-rate. We want to make sure that the
> first mitigation is sent as soon as possible.
> >
> > The two guards we have for this are discussed in Slide 8 of
> https://datatracker.ietf.org/meeting/106/materials/slides-106-dots-dots-
> signal-channel-heartbeat-mechanism-update-00.
> 
> 
> Great this is all fine.

[Med] Great. 

 I still think the wording in these sentences is
> confusing as it says "other congestion control checks”. Given this is
> already well defined, can we maybe just removed those two sentences (in
> order to avoid similar confusion as I had for the reader)?
> 

[Med] In order to have the guard enforced by the protocol, we can make with the following change:  

OLD: 
   Mitigation requests MUST NOT be delayed
   because of other congestion control checks.  Typically, mitigation
   requests must be sent without checks on probing rate (Section 4.7 of
   [RFC7252]).

NEW:
   Mitigation requests MUST NOT be delayed because of checks on
   probing rate (Section 4.7 of [RFC7252]). 

> > [Med] This is left to the implementation. Please note that we followed
> the same approach for when an old session expires (see for example, point
> #3 in this thread:
> https://mailarchive.ietf.org/arch/msg/dots/pdiC4xsbQiaazm14hvdTLefcUeY)
> 
> I was rather talking about the number of retries than an expiration time.
> E.g. one could say: "The DOTS client SHOULD try to reconnect RECON_NUM
> times with a default of RECON_NUM=5”

[Med] I don't think we need to define a retry logic at the DOTS layer given that DOTS relies upon the DTLS layer. 

DTLS layer will try sending ClientHello message multiple times till a timeout is reached: Please see https://tools.ietf.org/html/rfc6347#section-3.2.1 (ClientHello loss example) and https://tools.ietf.org/html/rfc6347#section-4.2.4.1. The number of retries will depend on the initial timer value. 

As discussed in 6347, timer values are implementation-specific.