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> Wed, 03 July 2019 18:05 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 A271112039C; Wed, 3 Jul 2019 11:05:15 -0700 (PDT)
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 N6I72PI9GtmL; Wed, 3 Jul 2019 11:05:13 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3921C12038E; Wed, 3 Jul 2019 11:05:13 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 45f8CW48c6z5wdt; Wed, 3 Jul 2019 20:05:11 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 45f8CW3LbCzDq7C; Wed, 3 Jul 2019 20:05:11 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM8F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Wed, 3 Jul 2019 20:05:11 +0200
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>, "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, "dots@ietf.org" <dots@ietf.org>, "frank.xialiang@huawei.com" <frank.xialiang@huawei.com>, The IESG <iesg@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "Benjamin Kaduk" <kaduk@mit.edu>
Thread-Topic: =?utf-8?B?QmVoYXZpb3Igd2hlbiBrZWVwLWFsaXZlcyBmYWlsIChSRTogW0RvdHNdICBN?= =?utf-8?B?aXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRvdHMt?= =?utf-8?Q?signal-channel-31:_(with_DISCUSS_and_COMMENT)?=
Thread-Index: AQHVMb9Ng3672ImM8Uie5akD8zLFOaa5LZPw
Date: Wed, 3 Jul 2019 18:05:10 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EAB349B@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> <D3F98780-F1AB-422F-BD3E-C2D59D97DDE0@kuehlewind.net>
In-Reply-To: <D3F98780-F1AB-422F-BD3E-C2D59D97DDE0@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/BkXGudz0ErdtkV3lfNr7iazRSts>
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: Wed, 03 Jul 2019 18:05:16 -0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind [mailto:ietf@kuehlewind.net]
> Envoyé : mercredi 3 juillet 2019 18:50
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : draft-ietf-dots-signal-channel@ietf.org; Konda, Tirumaleswar Reddy;
> dots@ietf.org; frank.xialiang@huawei.com; The IESG; dots-chairs@ietf.org;
> Benjamin Kaduk
> Objet : Re: Behavior when keep-alives fail (RE: [Dots] Mirja Kühlewind's
> Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
> 
> Hi Med,
> 
> See below.
> 
> > On 3. Jul 2019, at 15:46, <mohamed.boucadair@orange.com>;
> <mohamed.boucadair@orange.com>; wrote:
> >
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Mirja Kuehlewind [mailto:ietf@kuehlewind.net]
> >> Envoyé : mercredi 3 juillet 2019 14:46
> >> À : BOUCADAIR Mohamed TGI/OLN
> >> Cc : Konda, Tirumaleswar Reddy; Benjamin Kaduk; draft-ietf-dots-signal-
> >> channel@ietf.org; frank.xialiang@huawei.com; dots@ietf.org; The IESG;
> >> dots-chairs@ietf.org
> >> Objet : Re: Behavior when keep-alives fail (RE: [Dots] Mirja
> Kühlewind's
> >> Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and
> COMMENT)
> >>
> >> Hi Med,
> >>
> >> See below.
> >>
> >>> On 3. Jul 2019, at 12:48, <mohamed.boucadair@orange.com>;
> >> <mohamed.boucadair@orange.com>; wrote:
> >>>
> >>> Mirja,
> >>>
> >>>> Actually to my understanding this will not work. Both TCP heartbeat
> and
> >>>> Coap Ping are transmitted reliably. If you don’t receive an ack for
> >> these
> >>>> transmissions you are not able to send any additional messages and
> can
> >>>> only choose the connection.
> >>>
> >>> This behavior is implemented and tested between two implementations.
> The
> >> exact procedure is described in the draft, fwiw:
> >>>
> >>> ==
> >>>  When a Confirmable "CoAP Ping" is sent, and if there is no response,
> >>>  the "CoAP Ping" is retransmitted max-retransmit number of times by
> >>>  the CoAP layer using an initial timeout set to a random duration
> >>>  between ack-timeout and (ack-timeout*ack-random-factor) and
> >>>  exponential back-off between retransmissions.  By choosing the
> >>>  recommended transmission parameters, the "CoAP Ping" will timeout
> >>>  after 45 seconds.  If the DOTS agent does not receive any response
> >>>  from the peer DOTS agent for 'missing-hb-allowed' number of
> >>>  consecutive "CoAP Ping" Confirmable messages, it concludes that the
> >>>  DOTS signal channel session is disconnected.  A DOTS client MUST NOT
> >>>  transmit a "CoAP Ping" while waiting for the previous "CoAP Ping"
> >>>  response from the same DOTS server.
> >>> ==
> >>
> >> First, can you explain why you need 'missing-hb-allowed’?
> >
> > [Med] because we need to make sure this a "real/durable" session
> defunct, not a false positive. For example, this would have implications
> on the server as it may erroneously start automated mitigations (because
> it concludes the session is lost).
> 
> If the reliable ping fails, this means already that there where X number
> of reties which exponential backoff. This really should be an indication
> of a real failure!
> 

[Med] We spent in the WG a lot of cycles and time 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.

Please note that 'missing-hb-allowed' is configurable parameter that can be negotiated with the server. Also, the HB procedure can even be deactivated during idle time.