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

<> Thu, 12 December 2019 08:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BDB112084B; Thu, 12 Dec 2019 00:12:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yWFHOThDc3TA; Thu, 12 Dec 2019 00:12:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AFF7120843; Thu, 12 Dec 2019 00:12:37 -0800 (PST)
Received: from (unknown [xx.xx.xx.68]) by (ESMTP service) with ESMTP id 47YRNz53lQz5vwt; Thu, 12 Dec 2019 09:12:35 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by (ESMTP service) with ESMTP id 47YRNz3x81z1xnr; Thu, 12 Dec 2019 09:12:35 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([fe80::1c8e:403e:fbea:5835%21]) with mapi id 14.03.0468.000; Thu, 12 Dec 2019 09:12:35 +0100
From: <>
To: Mirja Kuehlewind <>
CC: "" <>, Benjamin Kaduk <>, "" <>, "" <>, The IESG <>
Thread-Topic: =?utf-8?B?W0RvdHNdICBCZWhhdmlvciB3aGVuIGtlZXAtYWxpdmVzIGZhaWwgKFJFOiAg?= =?utf-8?B?IE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZG90?= =?utf-8?Q?s-signal-channel-31:_(with_DISCUSS_and_COMMENT)?=
Thread-Index: AQHVsDKghyTqfmW8mkG2Vj2fPEN8F6e2FHdw
Date: Thu, 12 Dec 2019 08:12:35 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330313E9A1B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Thu, 12 Dec 2019 08:12:39 -0000

Hi Mirja,

Thank you for the feedback. 

Please see inline. 


> -----Message d'origine-----
> De : Mirja Kuehlewind []
> Envoyé : mercredi 11 décembre 2019 15:42
> Cc :; Benjamin Kaduk; dots-
>;; The IESG
> 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 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…?

[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


   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 

 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.

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

[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: