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

Mirja Kuehlewind <ietf@kuehlewind.net> Wed, 03 July 2019 10:25 UTC

Return-Path: <ietf@kuehlewind.net>
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 0EB7F12003F; Wed, 3 Jul 2019 03:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 JctsKpwmTU7b; Wed, 3 Jul 2019 03:25:37 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9D9120033; Wed, 3 Jul 2019 03:25:37 -0700 (PDT)
Received: from 200116b82468ed0068c3f61f5d01a906.dip.versatel-1u1.de ([2001:16b8:2468:ed00:68c3:f61f:5d01:a906]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hicSB-0004vL-W2; Wed, 03 Jul 2019 12:25:32 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAB2ABA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Wed, 3 Jul 2019 12:25:31 +0200
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F0E0BDCF-9D56-4547-86E3-FEBABD77A6EB@kuehlewind.net>
References: <787AE7BB302AE849A7480A190F8B93302EAB2ABA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1562149537;a640ad0b;
X-HE-SMSGID: 1hicSB-0004vL-W2
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/eK_RSIuBvDAWxrUCRNrOUDvl1Mw>
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:25:40 -0000

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