Re: [Dots] Improve controllability and predictability of keepalives

<mohamed.boucadair@orange.com> Wed, 20 November 2019 06:50 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 CAA2B120255 for <dots@ietfa.amsl.com>; Tue, 19 Nov 2019 22:50:11 -0800 (PST)
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 6MtTmbthOYj3 for <dots@ietfa.amsl.com>; Tue, 19 Nov 2019 22:50:08 -0800 (PST)
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 15448120801 for <dots@ietf.org>; Tue, 19 Nov 2019 22:50:08 -0800 (PST)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 47Htby1rzrz7vBH; Wed, 20 Nov 2019 07:50:06 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 47Htby186dzCqjh; Wed, 20 Nov 2019 07:50:06 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Wed, 20 Nov 2019 07:50:06 +0100
From: <mohamed.boucadair@orange.com>
To: Carsten Bormann <cabo@tzi.org>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: Improve controllability and predictability of keepalives
Thread-Index: AdWZOjG0GmH8bbOEScaak/2iE6U5+QGMEoNWAABNNcA=
Date: Wed, 20 Nov 2019 06:50:05 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330313DAD87@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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>
In-Reply-To: <BA7D4C74-73BF-4B7A-B211-01B20993E251@tzi.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Fe4bqHX0CUQ7LG-wC-yvF1v-tXg>
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:50:12 -0000

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