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 13:46 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 B4567120059; Wed, 3 Jul 2019 06:46:11 -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 bjr8TNeqNTcy; Wed, 3 Jul 2019 06:46:09 -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 EC0F61200C3; Wed, 3 Jul 2019 06:46:07 -0700 (PDT)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 45f2SZ2c65z10bC; Wed, 3 Jul 2019 15:46:06 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 45f2SZ1gvKzFpWq; Wed, 3 Jul 2019 15:46:06 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7D.corporate.adroot.infra.ftgroup ([fe80::bcfe:4850:e646:f223%21]) with mapi id 14.03.0439.000; Wed, 3 Jul 2019 15:46:05 +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: AQHVMZ1NUtpcwm0lbEyTBi3tKDy/rKa44R1w
Date: Wed, 3 Jul 2019 13:46:04 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EAB2F77@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>
In-Reply-To: <AA91C255-9CF2-4016-8538-E634C09C27EE@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/KP93TTXnBZSvK6W8UCyf0_EBhN0>
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 13:46:12 -0000

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 ping is
> transmitted reliably, one “missed” should be enough to conclude that the
> session is disconnected.

[Med] Hmm, under some DDoS attacks, both endpoints may be sending/replying to confirmable ping messages, but the reply may get  dropped. The session is not disconnected in such case.

> 
> Yes, as Coap Ping is used, the agent should not only conclude that the
> DOTS signal session is disconnected but also the Coap session and not send
> any further Coap messages anymore.
> 
> If you want to send further UDP datagram you should it unreliability and
> not more often then one per 3 seconds.
> 
> Mirja
> 
> 
> >
> > 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
> >>
> >>
> >