Re: [Dots] 2-way heartbeats 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 12:47 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 4BA7F120043; Wed, 3 Jul 2019 05:47:35 -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 jLEdLr2w-Tnp; Wed, 3 Jul 2019 05:47:33 -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 9C2F312000F; Wed, 3 Jul 2019 05:47:33 -0700 (PDT)
Received: from ip-109-42-2-15.web.vodafone.de ([109.42.2.15] helo=2-10.mgmt.ericsson.se); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hiefZ-00077j-Ta; Wed, 03 Jul 2019 14:47:30 +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: <787AE7BB302AE849A7480A190F8B93302EAB2CDD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Wed, 3 Jul 2019 14:47:25 +0200
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B8A2734-1A1E-474E-BE93-A8CDEF47AAAA@kuehlewind.net>
References: <787AE7BB302AE849A7480A190F8B93302EAB2B51@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <3044574C-65E5-4713-B2B5-02F305C8FDA2@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EAB2CDD@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;1562158053;9407716c;
X-HE-SMSGID: 1hiefZ-00077j-Ta
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/28buGqC-bUDaMoS5SHuYQgtfsoM>
Subject: Re: [Dots] =?utf-8?q?2-way_heartbeats_RE=3A___Mirja_K=C3=BChlewind?= =?utf-8?q?=27s_Discuss_on_draft-ietf-dots-signal-channel-31=3A_=28with_DI?= =?utf-8?q?SCUSS_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 12:47:35 -0000

Hi Med,

See below.

> On 3. Jul 2019, at 12:54, <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 12:13
>> À : 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: 2-way heartbeats RE: [Dots] Mirja Kühlewind's Discuss on
>> draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
>> 
>> Hi Med,
>> 
>> Please see below.
>> 
>>> On 3. Jul 2019, at 10:50, <mohamed.boucadair@orange.com>;
>> <mohamed.boucadair@orange.com>; wrote:
>>> 
>>> Mirja,
>>> 
>>> Your initial DISCUSS point was:
>>> 
>>> (1) "heartbeat should only be send in one direction (as the
>>> Other end will send an ack)"
>>> 
>>> We clarified that we need both HBs because there are cases where the
>> DOTS server needs to determine if the incoming link to the DOTS client is
>> saturated (due to an ongoing DDoS attack). It can conclude so because it
>> receives HBs from the client but no replies to its own HBs. The server
>> uses that information to tweak its mitigation strategy (in case a
>> mitigation is already in place). It also can conclude that the client
>> didn't detected an attack.
>> 
>> Here is the point that I don't understand: Let’s assume both ends are
>> sending pings but the client does not receive any pings from the server. I
>> would also that in this case the client would also not received any pongs
>> from the server (in response to their own ping),
> 
> [Med] Yes. The draft says:
> 
>   In case of a massive DDoS attack that saturates the incoming link(s)
>   to the DOTS client, all traffic from the DOTS server to the DOTS
>   client will likely be dropped, although the DOTS server receives
>   heartbeat requests in addition to DOTS messages sent by the DOTS
>   client.  
> 
> therefore believe that
>> the connection is Brocken, then close the connection and stop sending
>> pings, which then will be detected by the server. What do I miss?
> 
> [Med] No, we request the client to not close the connection under such conditions but continue to send the HBs to the server so that it can detect the link saturation issue:
> 
> ====
>   In this scenario, DOTS clients MUST behave differently to
>   handle message transmission and DOTS signal channel session
>   liveliness during link saturation:
> 
>      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
> 
> =====

I believe this is now the same conversation as in the other thread about use of keep-alives in vernal, so let’s keep to there.

Mirja


> 
>> 
>> Mirja
>> 
>> 
>> 
>>> 
>>> To which you suggested the following:
>>> 
>>> (2) "what you described implies that the server should send the ping and
>> client sends the pong. This is fine."
>>> 
>>> We clarified that pings from the server may be discarded by on path
>> NATs/FWs. The HBs from the client are also meant to maintain a state alive
>> in those functions.
>>> 
>>> We also reminded that 8085 recommends "to ** independently ** check both
>> directions" for long-lived association. We are adhering to that
>> recommendation.
>>> 
>>> Can you please let us know how we can achieve the above with one single
>> HB direction? Thank you.
>>> 
>>> 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)
>>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>>> 6) Section 4.7: "the DOTS
>>>>>>>>> agent sends a heartbeat over the signal channel to maintain its
>>>> half
>>>>>>>>> of the channel.  The DOTS agent similarly expects a heartbeat from
>>>>>>>>> its peer DOTS agent"
>>>>>>>>> and
>>>>>>>>> "DOTS servers MAY trigger their heartbeat requests immediately
>> after
>>>>>>>>> receiving heartbeat probes from peer DOTS clients."
>>>>>>>>> Actually heartbeat should only be send in one direction (as the
>>>> other
>>>>>>>>> end will send an ack) and the protocol should clearly specify
>> which
>>>>>>>>> endpoint is responsible for triggering the ping.
>>>>>>>> 
>>>>>>>> I'm not sure I see resolution on this; do the authors still need to
>>>>>> answer why
>>>>>>>> the "pong" reply cannot serve as a reverse-path heartbeat?
>>>>>>> 
>>>>>>> If the DOTS client domain is subjected to volumetric DDoS attack and
>>>> the
>>>>>> incoming link is saturated, the pong response from the server will
>> not
>>>>>> reach the client. DOTS server gets traffic from the client but
>> receives
>>>> no
>>>>>> responses to its ping requests indicating the client has not detected
>>>> the
>>>>>> attack or, if an attack mitigation is in progress, it implies the
>>>> applied
>>>>>> DDoS mitigation actions are not yet effective to handle the DDoS
>> attack
>>>>>> volume.
>>>>>> 
>>>>>> Yes, I understand what heartbeat are used for. However, what you
>>>> described
>>>>>> implies that the server should send the ping and client sends the
>> pong.
>>>>>> This is fine.
>>>>> 
>>>>> [Med] Choosing the other way around may be problematic because of
>>>> NAT/FWs. This is why the heartbeats from the server will fly right
>> after
>>>> the one from the client so that we can use the warm mappings. Having
>> both
>>>> directions allows to accommodate the scenario described by Tiru.
>>>>> 
>>>>> As you know, RFC4787 mandates the NAT outbound refresh behavior
>> (packets
>>>> go from the internal side of the NAT to the external side of the NAT to
>>>> refresh the timer value) but not the NAT inbound refresh behavior.
>>>>> 
>>>>> The text however seems to imply that both server and client
>>>>>> test their have connection separately and both send pings and pongs.
>>>> That
>>>>>> doesn’t seem to be need.
>>>>> 
>>>>> [Med] In addition to the clarification above, we have also added a
>>>> pointer to this part of 8085:
>>>>> 
>>>>> ==
>>>>> A UDP application with a long-lived association between the sender
>>>>> and receiver, ought to be designed so that the sender periodically
>>>>> checks that the receiver still wants ("consents") to receive traffic
>>>>> and need to be designed to stop if there is no explicit confirmation
>>>>> of this [RFC7675].  Applications that require communications in two
>>>>> directions to implement protocol functions (such as reliability or
>>>>> congestion control) will need to independently check both directions
>>>>>                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> of communication, and may have to exchange keep-alive messages to
>>>>> ^^^^^^^^^^^^^^^^
>>>>> traverse middleboxes (see Section 3.5).
>>>>> ==
>>>> 
>>>> Yes, you use keep-alive messages here. A ping on one direction and a
>>>> pong/ack as reply in the direction. I’m not we are maybe talking past
>> each
>>>> other… I think the following is sufficient
>>>> 
>>>> 
>>>> Client ping —————>
>>>>           <———— server pong
>>>> 
>>>> 
>>>> While what I read from the document is that you do this:
>>>> 
>>>> Client ping —————>
>>>>           <———— server pong
>>>> 
>>>>           <———— server ping
>>>> Client pong —————>
>>>> 
>>>> If that is not what your are doing you need to clarify this in the
>>>> document.
>>>> 
>>>> If you actually want to have two different ping/pong’s you need to
>> explain
>>>> me why you need both.
>>> 
>