Re: [Dots] Improve controllability and predictability of keepalives

<mohamed.boucadair@orange.com> Wed, 20 November 2019 07:00 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 1EFC412080F for <dots@ietfa.amsl.com>; Tue, 19 Nov 2019 23:00:54 -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 itB9Ba7HKjSQ for <dots@ietfa.amsl.com>; Tue, 19 Nov 2019 23:00:49 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1053120818 for <dots@ietf.org>; Tue, 19 Nov 2019 23:00:48 -0800 (PST)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 47HtrH1D3dzFqTK; Wed, 20 Nov 2019 08:00:47 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 47HtrH0HVszCqkT; Wed, 20 Nov 2019 08:00:47 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7C.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Wed, 20 Nov 2019 08:00:46 +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+QGNMAI+AAA8O7A=
Date: Wed, 20 Nov 2019 07:00:46 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330313DADAE@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> <787AE7BB302AE849A7480A190F8B9330313DAD87@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0BA3CB18-4B5D-4EC8-8FD1-29EB3AF4D556@tzi.org>
In-Reply-To: <0BA3CB18-4B5D-4EC8-8FD1-29EB3AF4D556@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/uRKASM2Qd__3Gufs9s05TC0ME3w>
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 07:00:54 -0000

Re-,

Thank you, Carsten.

I will submit the new version soon.

Cheers,
Med

> -----Message d'origine-----
> De : Carsten Bormann [mailto:cabo@tzi.org]
> Envoyé : mercredi 20 novembre 2019 07:51
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : dots@ietf.org
> Objet : Re: Improve controllability and predictability of keepalives
> 
> 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