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

<mohamed.boucadair@orange.com> Thu, 12 December 2019 08:12 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDB112084B; Thu, 12 Dec 2019 00:12:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWFHOThDc3TA; Thu, 12 Dec 2019 00:12:37 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AFF7120843; Thu, 12 Dec 2019 00:12:37 -0800 (PST)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr23.francetelecom.fr (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 opfednr04.francetelecom.fr (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: <mohamed.boucadair@orange.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
CC: "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "dots@ietf.org" <dots@ietf.org>, The IESG <iesg@ietf.org>
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> <F0E0BDCF-9D56-4547-86E3-FEBABD77A6EB@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EAB2CC5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <AA91C255-9CF2-4016-8538-E634C09C27EE@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EAB2F77@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <06e901d531a8$38f38d90$aadaa8b0$@jpshallow.com> <2B716406-0554-4DC6-B6F9-057A9D4D85C4@kuehlewind.net> <072901d531d3$bdd39c00$397ad400$@jpshallow.com> <DM5PR16MB170501C0B9CF2A8BB2177C78EACF0@DM5PR16MB1705.namprd16.prod.outlook.com> <75AF98A2-C7AE-48DD-B054-F25CCA2C8367@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302F643236@OPEXCNORMAE.corporate.adroot.infra.ftgroup> <B8804DF4-BF94-4E28-9CA3-54081E61CFFE@kuehlewind.net>
In-Reply-To: <B8804DF4-BF94-4E28-9CA3-54081E61CFFE@kuehlewind.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/dNXyVoZY-1xr5RKRbEl9xwBRmno>
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-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2019 08:12:39 -0000

Hi Mirja,

Thank you for the feedback. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind [mailto:ietf@kuehlewind.net]
> Envoyé : mercredi 11 décembre 2019 15:42
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : draft-ietf-dots-signal-channel@ietf.org; Benjamin Kaduk; dots-
> chairs@ietf.org; dots@ietf.org; 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

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.

> 
> 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: https://mailarchive.ietf.org/arch/msg/dots/pdiC4xsbQiaazm14hvdTLefcUeY)