Re: [Dots] Improve controllability and predictability of keepalives

Carsten Bormann <cabo@tzi.org> Wed, 20 November 2019 06:51 UTC

Return-Path: <cabo@tzi.org>
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 0F4D7120801 for <dots@ietfa.amsl.com>; Tue, 19 Nov 2019 22:51:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 Hdp2V0HgENEN for <dots@ietfa.amsl.com>; Tue, 19 Nov 2019 22:51:32 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B631120255 for <dots@ietf.org>; Tue, 19 Nov 2019 22:51:32 -0800 (PST)
Received: from dhcp-9c88.meeting.ietf.org (dhcp-9c88.meeting.ietf.org [31.133.156.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47HtdZ3mb4z107g; Wed, 20 Nov 2019 07:51:30 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330313DAD87@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Wed, 20 Nov 2019 14:51:28 +0800
Cc: "dots@ietf.org" <dots@ietf.org>
X-Mao-Original-Outgoing-Id: 595925486.434535-decb5dad1a1c1321795bf880c6d8f30a
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BA3CB18-4B5D-4EC8-8FD1-29EB3AF4D556@tzi.org>
References: <787AE7BB302AE849A7480A190F8B9330313624A5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <18CFEB6A-81B8-44A4-B749-DB1689E0B442@tzi.org> <787AE7BB302AE849A7480A190F8B933031362BF5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313D3421@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <8E353427-9380-44CF-B151-63DB0106BFCA@tzi.org> <787AE7BB302AE849A7480A190F8B9330313D89A8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BA7D4C74-73BF-4B7A-B211-01B20993E251@tzi.org> <787AE7BB302AE849A7480A190F8B9330313DAD87@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/C9Gte7lR3q-l9qm8JnIBy_diQEY>
Subject: Re: [Dots] Improve controllability and predictability of keepalives
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, 20 Nov 2019 06:51:35 -0000

Thank you.

I think my concerns are addressed.

Grüße, Carsten


> On Nov 20, 2019, at 14:50, <mohamed.boucadair@orange.com>; <mohamed.boucadair@orange.com>; wrote:
> 
> Hi Carsten, 
> 
> Please see inline.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Carsten Bormann [mailto:cabo@tzi.org]
>> Envoyé : mercredi 20 novembre 2019 07:20
>> À : BOUCADAIR Mohamed TGI/OLN
>> Cc : dots@ietf.org
>> Objet : Re: Improve controllability and predictability of keepalives
>> 
>>>> Thank you.
>>>> I still have a few questions, but I think this looks very good.
>>>> 
>>>> 4.4 says:
>>>>          Mitigation requests MUST NOT be delayed
>>>> 	   because of other congestion control checks.
>>>> What might those be?
>>> 
>>> [Med] A too low probing rate for example as indicated in the sentence
>> right after that excerpt. There is a risk that mitigation requests are
>> delayed (or that heartbeats are not sent which may lead to session liveness
>> checks).
>>> 
>>> 
>>>> (You don’t want to be in a situation where you send a ton of mitigation
>>>> requests that are mostly dropped at the tail of a queue.)
>>>> 
>>> 
>>> [Med] Yes, we don't that. The authoritative rule is as follows:
>>> 
>>>  Requests marked by the DOTS client as Non-confirmable messages are
>>>  sent at regular intervals until a response is received from the DOTS
>>>  server.  If the DOTS client cannot maintain an RTT estimate, it MUST
>>>  NOT send more than one Non-confirmable request every 3 seconds, and
>>>  SHOULD use an even less aggressive rate whenever possible (case 2 in
>>>  Section 3.1.3 of [RFC8085]).
>> 
>> And if it can?
> 
> [Med] It does the following: 
> 
>   DOTS agents MUST NOT send more than one UDP datagram per round-trip
>   time (RTT) to the peer DOTS agent on average ...
> 
>> 
>>> 
>>> 
>>>> Before Figure 27, it says:
>>>> 
>>>>          The PUT request used for DOTS heartbeat MUST NOT have a
>>>> 	   'cuid', 'cdid,' or 'mid' Uri-Path.  Such PUT requests MUST NOT be
>>>> 
>>>> 	   relayed by DOTS gateways.
>>>> 
>>>> Why?  (And what should the DOTS gateways do instead?)
>>> 
>>> [Med] Session loss detect and recovery is local to an agent and its
>> immediate peer. Heartbeats are thus not relayed.
>> 
>> Ah, I was confused.
>> Where is “DOTS gateway” defined?
> 
> [Med] It is defined in draft-ietf-dots-architecture-14#section-2.2.3: 
> 
> =====
>   Traditional client/server relationships may be expanded by chaining
>   DOTS sessions.  This chaining is enabled through "logical
>   concatenation" of a DOTS server and a DOTS client.
> 
>   A DOTS gateway may be deployed client-side, server-side or both.  The
>   gateway may terminate multiple discrete client connections and may
>   aggregate these into a single or multiple DOTS sessions.
> 
>   The DOTS gateway will appear as a server to its downstream agents and
>   as a client to its upstream agents, a functional concatenation of the
>   DOTS client and server roles, as depicted in Figure 4:
> 
>                         +-------------+
>                         |    | D |    |
>         +----+          |    | O |    |         +----+
>         | c1 |----------| s1 | T | c2 |---------| s2 |
>         +----+          |    | S |    |         +----+
>                         |    | G |    |
>                         +-------------+
> ======
> 
>> I’m assuming this is not like a CoAP Proxy?
>> It would need to expose the equivalent to /hb.
> 
> [Med] Yes, nevertheless the client does not need to assess the end-to-end connection, but only the one it uses to place its mitigation requests (it is not even aware about the existence of the ultimate server). Likewise, the server domain (includes both gw and server) does only need to assess if it can reach out a client to trigger. 
> 
>> 
>>> We can update as follows:
>>> 
>>> "This procedure occurs between a DOTS agent and its immediate peer DOTS
>> agent. As such, this GET request MUST NOT be relayed by a DOTS gateway. The
>> PUT request used for DOTS heartbeat MUST NOT have a ‘cuid', 'cdid,' or
>> 'mid' Uri-Path."
>> 
>> This doesn’t quite address the above, though.
>> 
>> Grüße, Carsten