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 10:48 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 C17ED1204E0; Wed, 3 Jul 2019 03:48:21 -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 TttaCYz6ExNi; Wed, 3 Jul 2019 03:48:19 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC5D12021C; Wed, 3 Jul 2019 03:48:19 -0700 (PDT)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 45dyWP4TJnz5y9w; Wed, 3 Jul 2019 12:48:17 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 45dyWP2Vmbz5vMv; Wed, 3 Jul 2019 12:48:17 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5E.corporate.adroot.infra.ftgroup ([fe80::849f:f804:b713:d99a%21]) with mapi id 14.03.0439.000; Wed, 3 Jul 2019 12:48:17 +0200
From: <mohamed.boucadair@orange.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
CC: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, "Benjamin Kaduk" <kaduk@mit.edu>, "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, "frank.xialiang@huawei.com" <frank.xialiang@huawei.com>, "dots@ietf.org" <dots@ietf.org>, The IESG <iesg@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>
Thread-Topic: =?utf-8?B?QmVoYXZpb3Igd2hlbiBrZWVwLWFsaXZlcyBmYWlsIChSRTogW0RvdHNdICBN?= =?utf-8?B?aXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRvdHMt?= =?utf-8?Q?signal-channel-31:_(with_DISCUSS_and_COMMENT)?=
Thread-Index: AQHVMYmnynjuqGVJJkeMQs1PdNNQfaa4tPKw
Date: Wed, 3 Jul 2019 10:48:16 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EAB2CC5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B93302EAB2ABA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <F0E0BDCF-9D56-4547-86E3-FEBABD77A6EB@kuehlewind.net>
In-Reply-To: <F0E0BDCF-9D56-4547-86E3-FEBABD77A6EB@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/-dC2LQc-Xx6MWEayzWMxNawsU9U>
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 10:48:22 -0000

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

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind [mailto:ietf@kuehlewind.net]
> Envoyé : mercredi 3 juillet 2019 12:26
> À : 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 09:53, mohamed.boucadair@orange.com wrote:
> >
> > Hi Mirja,
> >
> > (Focusing on individual issues)
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Mirja Kuehlewind [mailto:ietf@kuehlewind.net]
> >> Envoyé : mardi 2 juillet 2019 16:00
> >> À : 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: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-signal-
> >> channel-31: (with DISCUSS and COMMENT)
> >>
> > ...
> >>>>>>> 10) The document should more explicitly provide more guidance
> about
> >>>>>>> when a client should start a session and what should be done (from
> >> the
> >>>>>>> client side) if a session is detected as inactive (other than
> during
> >>>>>>> migration which is discussed a bit in 4.7). Is the assumption to
> >> have
> >>>>>>> basically permanently an active session or connect for migration
> and
> >>>>>>> configuration requests separately at a time?
> >>>>>>
> >>>>>> I think there was some clarifying text added, but please confirm if
> >> you
> >>>> think it
> >>>>>> is sufficient.
> >>>>
> >>>> Sorry, don’t see where text was added. Can you provide a pointer?
> >>>
> >>> [Med] We do have this text, for example:
> >>>
> >>>  The DOTS signal channel can be established between two DOTS agents
> >>>  prior or during an attack.  The DOTS signal channel is initiated by
> >>>  the DOTS client.  The DOTS client can then negotiate, configure, and
> >>>  retrieve the DOTS signal channel session behavior with its DOTS peer
> >>>  (Section 4.5).  Once the signal channel is established, the DOTS
> >>>  agents periodically send heartbeats to keep the channel active
> >>>  (Section 4.7).  At any time, the DOTS client may send a mitigation
> >>>  request message (Section 4.4) to a DOTS server over the active signal
> >>>  channel.  While mitigation is active (because of the higher
> >>>  likelihood of packet loss during a DDoS attack), the DOTS server
> >>>  periodically sends status messages to the client, including basic
> >>>  mitigation feedback details.  Mitigation remains active until the
> >>>  DOTS client explicitly terminates mitigation, or the mitigation
> >>>  lifetime expires.  Also, the DOTS server may rely on the signal
> >>>  channel session loss to trigger mitigation for pre-configured
> >>>  mitigation requests (if any).
> >>
> >> Okay thanks for for the pointer. What I think is missing are some
> >> sentences about what the client (or server) should do if the keep-alive
> >> fails. Try to reconnect directly or just with the next request or
> >> whatever. Basically who should reconnect and when?
> >
> > [Med] This is discussed in details in Section 4.7, in particular.
> >
> > As a generic rule, it is always the client who connects (see the excerpt
> above).
> >
> > The server may use the failure to initiate automated mitigation (see the
> excerpt above). More details are provided in other sections.
> >
> > There are several heartbeat failure cases to handle by the client.
> Examples from 4.7 are provided below, fwiw:
> >
> >      The DOTS client MUST NOT consider the DOTS signal channel session
> >      terminated even after a maximum 'missing-hb-allowed' threshold is
> >      reached.  The DOTS client SHOULD keep on using the current DOTS
> >      signal channel session to send heartbeat requests over it, so that
> >      the DOTS server knows the DOTS client has not disconnected the
> >      DOTS signal channel session.
> >
> >      After the maximum 'missing-hb-allowed' threshold is reached, the
> >      DOTS client SHOULD try to resume the (D)TLS session.  The DOTS
> >      client SHOULD send mitigation requests over the current DOTS
> >      signal channel session, and in parallel, for example, try to
> >      resume the (D)TLS session or use 0-RTT mode in DTLS 1.3 to
> >      piggyback the mitigation request in the ClientHello message.
> >
> >      As soon as the link is no longer saturated, if traffic from the
> >      DOTS server reaches the DOTS client over the current DOTS signal
> >      channel session, the DOTS client can stop (D)TLS session
> >      resumption or if (D)TLS session resumption is successful then
> >      disconnect the current DOTS signal channel session.
> >
> > Do you think additional text is needed?
> 
> 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.
> 
> Mirja
> 
>