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

Mirja Kuehlewind <> Wed, 11 December 2019 14:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4905F12021C; Wed, 11 Dec 2019 06:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yWVCj5uf9tGq; Wed, 11 Dec 2019 06:52:36 -0800 (PST)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92A5E120271; Wed, 11 Dec 2019 06:52:36 -0800 (PST)
Received: from [] (helo=[]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1if3Lr-0005x0-KL; Wed, 11 Dec 2019 15:52:31 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302F643236@OPEXCNORMAE.corporate.adroot.infra.ftgroup>
Date: Wed, 11 Dec 2019 15:42:25 +0100
Cc: "" <>, Benjamin Kaduk <>, "" <>, "" <>, The IESG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <787AE7BB302AE849A7480A190F8B93302EAB2ABA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93302EAB2CC5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93302EAB2F77@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <06e901d531a8$38f38d90$aadaa8b0$> <> <072901d531d3$bdd39c00$397ad400$> <> <> <787AE7BB302AE849A7480A190F8B93302F643236@OPEXCNORMAE.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3445.104.11)
X-HE-SMSGID: 1if3Lr-0005x0-KL
Archived-At: <>
Subject: Re: [Dots] =?utf-8?q?Behavior_when_keep-alives_fail_=28RE=3A___Mirja?= =?utf-8?q?_K=C3=BChlewind=27s_Discuss_on_draft-ietf-dots-signal-channel-3?= =?utf-8?q?1=3A_=28with_DISCUSS_and_COMMENT=29?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Dec 2019 14:52:39 -0000

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


> On 17. Jul 2019, at 14:15, 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 []
>> Envoyé : mardi 16 juillet 2019 17:41
>> À : Konda, Tirumaleswar Reddy
>> Cc : Jon Shallow; BOUCADAIR Mohamed TGI/OLN; draft-ietf-dots-signal-
>>;;; The IESG;
>>; 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