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> Fri, 13 December 2019 10:10 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 3F441120830; Fri, 13 Dec 2019 02:10: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 7M4qFf8kRF-C; Fri, 13 Dec 2019 02:10:37 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F3912026E; Fri, 13 Dec 2019 02:10:37 -0800 (PST)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 47Z5yg2gMBz5vgc; Fri, 13 Dec 2019 11:10:35 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 47Z5yg11d0z5vNf; Fri, 13 Dec 2019 11:10:35 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905%18]) with mapi id 14.03.0468.000; Fri, 13 Dec 2019 11:10:34 +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: AQHVsQz6y2bvEJI5nEGtT95kVajpoqe3rjYg
Date: Fri, 13 Dec 2019 10:10:34 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330313EA7C5@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> <787AE7BB302AE849A7480A190F8B9330313E9A1B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <F68A8E80-06A9-40C0-8AB2-F7DC9D9B3303@kuehlewind.net>
In-Reply-To: <F68A8E80-06A9-40C0-8AB2-F7DC9D9B3303@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/B1qrMGzv2vr_Le0ocPGNTr31g9U>
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: Fri, 13 Dec 2019 10:10:39 -0000

Hi Mirja, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind [mailto:ietf@kuehlewind.net]
> Envoyé : jeudi 12 décembre 2019 17:56
> À : 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,
> 
> See below.
> 
> > On 12. Dec 2019, at 09:12, mohamed.boucadair@orange.com wrote:
> >
> > 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.
> 
> 
> 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]). 


> >
> >
> > 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)
> 
> 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?
> 

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