Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)

<mohamed.boucadair@orange.com> Mon, 22 July 2019 15:03 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 A75CE120288; Mon, 22 Jul 2019 08:03:28 -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 evjFu5uMGcf7; Mon, 22 Jul 2019 08:03:23 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3702F12030E; Mon, 22 Jul 2019 08:03:23 -0700 (PDT)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 45slGy0Fqkz5vfV; Mon, 22 Jul 2019 17:03:22 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 45slGx6XBHzDq7V; Mon, 22 Jul 2019 17:03:21 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Mon, 22 Jul 2019 17:03:21 +0200
From: <mohamed.boucadair@orange.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, "Valery Smyslov" <valery@smyslov.net>, 'Benjamin Kaduk' <kaduk@mit.edu>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
Thread-Index: AdU9/zWZw7DhsbF6RNCA2PYrEJMCCAAJ+IgAAABxlPAAHmWBgABucluAAAF8LhAAA+q90AABWUtgAAFZ9uAABONuAAAAWKWAAACgKrAAAmmhIA==
Date: Mon, 22 Jul 2019 15:03:21 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330312E3A41@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B93302FA841A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <00c201d53e27$194cfc20$4be6f460$@smyslov.net> <DM5PR16MB1705B5FC8E9204012E34636FEACB0@DM5PR16MB1705.namprd16.prod.outlook.com> <011701d53ea2$74d81540$5e883fc0$@smyslov.net> <787AE7BB302AE849A7480A190F8B9330312E32E9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <DM5PR16MB17050AC5EABA8D76DDB42ACBEAC40@DM5PR16MB1705.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B9330312E3433@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <DM5PR16MB1705DFCE2F9B379A36FD79AAEAC40@DM5PR16MB1705.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B9330312E34A0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <DM5PR16MB170553F3A8B1F3F1ED59D509EAC40@DM5PR16MB1705.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B9330312E3792@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <DM5PR16MB170505ABB7555E0ADCEC1BC6EAC40@DM5PR16MB1705.namprd16.prod.outlook.com>
In-Reply-To: <DM5PR16MB170505ABB7555E0ADCEC1BC6EAC40@DM5PR16MB1705.namprd16.prod.outlook.com>
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/e-QGd5W3eym12gQg4cMzGyakua8>
Subject: Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
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: Mon, 22 Jul 2019 15:03:33 -0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
> Envoyé : lundi 22 juillet 2019 16:02
> À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; 'Benjamin Kaduk'; dots-
> chairs@ietf.org; dots@ietf.org
> Objet : RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> 
> > -----Original Message-----
> > From: mohamed.boucadair@orange.com
> > <mohamed.boucadair@orange.com>
> > Sent: Monday, July 22, 2019 7:09 PM
> > To: Konda, Tirumaleswar Reddy
> > <TirumaleswarReddy_Konda@McAfee.com>om>; Valery Smyslov
> > <valery@smyslov.net>et>; 'Benjamin Kaduk' <kaduk@mit.edu>du>; dots-
> > chairs@ietf.org; dots@ietf.org
> > Subject: RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> >
> > This email originated from outside of the organization. Do not click
> links or
> > open attachments unless you recognize the sender and know the content is
> > safe.
> >
> > Re-,
> >
> > > Yes, but 30 seconds of timeout looks too aggressive. I suggest we use
> > > 2 minutes (UDP uses 105 seconds) of heartbeat-interval.
> >
> > 30 seconds is recommended value for UDP (as this is our favorite
> transport).
> 
> I meant use 2 minutes for TCP (UDP heartbeat interval is 30 seconds, and
> the timeout happens after 105 seconds).
> 

[Med] The reco we have for UDP was driven by NAT considerations. For TCP, why using 2 minutes is better than 5 minutes and so on? I'm afraid we don't have such argument. This is why I prefer to leave this deployment-specific. Please remember that using TCP as transport is not the recommended one. 

> >
> > If TCP is used, this falls into the following:
> >
> >       DOTS agents may
> >       negotiate longer heartbeat-interval values to prevent any network
> >       overload with too frequent keepalives.
> 
> The above line is deployment specific not transport specific.

[Med] Deployment considerations cover transport ones.  

> >
> > Even if we include another recommended value for TCP, I'm afraid it is
> not
> > possible to reflect this in the YANG module:
> >
> >          leaf current-value {
> >            type uint16;
> >            units "seconds";
> >            default "30";
> >            description
> >              "Current heartbeat-interval value.
> >
> >               '0' means that heartbeat mechanism is deactivated.";
> >          }
> 
> Yes, it is YANG limitation but not stop the protocol from giving a
> recommendation for TCP.

[Med] The issue is that we need to be consistent: the parameter applies for all transport. We cannot set two defaults for it.  

> 
> Cheers,
> -Tiru
> 
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Konda, Tirumaleswar Reddy
> > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > Envoyé : lundi 22 juillet 2019 15:27
> > > À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; 'Benjamin Kaduk';
> > dots-
> > > chairs@ietf.org; dots@ietf.org Objet : RE: [Dots] Mirja's DISCUSS:
> > > Pending Point (AD Help Needed)
> > >
> > > > -----Original Message-----
> > > > From: mohamed.boucadair@orange.com
> > > > <mohamed.boucadair@orange.com>
> > > > Sent: Monday, July 22, 2019 4:32 PM
> > > > To: Konda, Tirumaleswar Reddy
> > > > <TirumaleswarReddy_Konda@McAfee.com>om>; Valery Smyslov
> > > > <valery@smyslov.net>et>; 'Benjamin Kaduk' <kaduk@mit.edu>du>; dots-
> > > > chairs@ietf.org; dots@ietf.org
> > > > Subject: RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> > > >
> > > >
> > > >
> > > > Re-,
> > > >
> > > > Please see inline.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -----Message d'origine-----
> > > > > De : Konda, Tirumaleswar Reddy
> > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > > > Envoyé : lundi 22 juillet 2019 12:25 À : BOUCADAIR Mohamed
> > > > > TGI/OLN; Valery Smyslov; 'Benjamin Kaduk';
> > > > dots-
> > > > > chairs@ietf.org; dots@ietf.org Objet : RE: [Dots] Mirja's DISCUSS:
> > > > > Pending Point (AD Help Needed)
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Dots <dots-bounces@ietf.org> On Behalf Of
> > > > > > mohamed.boucadair@orange.com
> > > > > > Sent: Monday, July 22, 2019 3:16 PM
> > > > > > To: Konda, Tirumaleswar Reddy
> > > > > > <TirumaleswarReddy_Konda@McAfee.com>om>; Valery Smyslov
> > > > > > <valery@smyslov.net>et>; 'Benjamin Kaduk' <kaduk@mit.edu>du>; dots-
> > > > > > chairs@ietf.org; dots@ietf.org
> > > > > > Subject: Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help
> > > > > > Needed)
> > > > > >
> > > > > > This email originated from outside of the organization. Do not
> > > > > > click
> > > > > links or
> > > > > > open attachments unless you recognize the sender and know the
> > > > > > content is safe.
> > > > > >
> > > > > > Re-,
> > > > > >
> > > > > > Please see inline.
> > > > > >
> > > > > > Cheers,
> > > > > > Med
> > > > > >
> > > > > > > -----Message d'origine-----
> > > > > > > De : Konda, Tirumaleswar Reddy
> > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > > > > > Envoyé : lundi 22 juillet 2019 10:58 À : BOUCADAIR Mohamed
> > > > > > > TGI/OLN; Valery Smyslov; 'Benjamin Kaduk';
> > > > > > dots-
> > > > > > > chairs@ietf.org; dots@ietf.org Objet : RE: [Dots] Mirja's
> DISCUSS:
> > > > > > > Pending Point (AD Help Needed)
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: mohamed.boucadair@orange.com
> > > > > > > > <mohamed.boucadair@orange.com>
> > > > > > > > Sent: Monday, July 22, 2019 12:38 PM
> > > > > > > > To: Valery Smyslov <valery@smyslov.net>et>; Konda, Tirumaleswar
> > > > > > > > Reddy <TirumaleswarReddy_Konda@McAfee.com>om>; 'Benjamin
> > > > Kaduk'
> > > > > > > > <kaduk@mit.edu>du>; dots-chairs@ietf.org; dots@ietf.org
> > > > > > > > Subject: RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help
> > > > > > > > Needed)
> > > > > > > >
> > > > > > > > This email originated from outside of the organization. Do
> > > > > > > > not click
> > > > > > > links or
> > > > > > > > open attachments unless you recognize the sender and know
> > > > > > > > the content is safe.
> > > > > > > >
> > > > > > > > Hi Valery,
> > > > > > > >
> > > > > > > > Actually, we have clarified that (see for example,
> > > > > > > > https://mailarchive.ietf.org/arch/msg/dots/21wgxXEy-
> > > > > > > > vWecFZK9BeviBFMdnA)
> > > > > > > >
> > > > > > > > > All the message transmission parameters including
> > > > > > > > > missing-hb- allowed are configurable using the DOTS signal
> > > > > > > > > channel (see
> > > > > > > > > draft-ietf-
> > > > > > > > > dots-signal-channel-35#section-4.5) and these message
> > > > > > > > > transmission parameter including the missing-hb-allowed is
> > > > > > > > > only used for UDP
> > > > > > > transport.
> > > > > > > >
> > > > > > > > We can add this NEW text to Section 4.5 If this would help:
> > > > > > > >
> > > > > > > >    When the DOTS signal channel is established over a
> > > > > > > > reliable
> > > > > transport
> > > > > > > >    (e.g., TCP), there is no need for the reliability
> > > > > > > > mechanisms
> > > > > provided
> > > > > > > >    by CoAP over UDP since the underlying TCP connection
> provides
> > > > > > > >    retransmissions and deduplication [RFC8323].  As such,
> the
> > > > > > > >    transmission-related parameters (missing-hb-allowed and
> > > > > acceptable
> > > > > > > >    signal loss ratio) are negotiated only for DOTS over
> > > unreliable
> > > > > > > >    transports.
> > > > > > >
> > > > > > > I propose to slightly modify the text as follows:
> > > > > > >
> > > > > > >     When the DOTS signal channel is established over a
> > > > > > > reliable
> > > > > transport
> > > > > > >     (e.g., TCP), there is no need for the reliability
> > > > > > > mechanisms
> > > > > provided
> > > > > > >     by CoAP over UDP since the underlying TCP connection
> provides
> > > > > > >     retransmissions and deduplication [RFC8323].  As a
> > > > > > > reminder, Confirmable  and Non-confirmable message types are
> > > > > > > specific to unreliable transport, and
> > > > > > >     are not supported in CoAP over TCP.  As such, the message
> > > > > > >     transmission-related parameters (missing heartbeats
> > > > > > > allowed and acceptable
> > > > > > >     signal loss ratio) are negotiated only for DOTS over
> > > unreliable
> > > > > > >     transports.
> > > > > >
> > > > > > [Med] OK. I went with the following:
> > > > > >
> > > > > >    When the DOTS signal channel is established over a reliable
> > > transport
> > > > > >    (e.g., TCP), there is no need for the reliability mechanisms
> > > provided
> > > > > >    by CoAP over UDP since the underlying TCP connection provides
> > > > > >    retransmissions and deduplication [RFC8323].  As a reminder,
> CoAP
> > > > > >    over reliable transports does not support Confirmable or Non-
> > > > > >    confirmable message types.  As such, the transmission-related
> > > > > >    parameters (missing-hb-allowed and acceptable signal loss
> > > > > > ratio)
> > > are
> > > > > >    negotiated only for DOTS over unreliable transports.
> > > > >
> > > > > Looks good.
> > > > >
> > > > > >
> > > > > >
> > > > > > If the CoAP ping us unacknowledged for a specific duration
> > > > > > > (i.e. TCP user timeout expires), TCP will forcefully close the
> > > > > > > connection, and the DOTS client will have
> > > > > > >      to re-establish the TCP connection.
> > > > > > >
> > > > > >
> > > > > > [Med] and made this change:
> > > > > >
> > > > > > OLD:
> > > > > >    In DOTS over TCP, heartbeat messages MUST be exchanged
> > > > > > between
> > > > the
> > > > > >    DOTS agents using the Ping and Pong messages specified in
> > > > > > Section
> > > 5.4
> > > > > >    of [RFC8323].  That is, the DOTS agent sends a Ping message
> > > > > > and
> > > the
> > > > > >    peer DOTS agent would respond by sending a single Pong
> message.
> > > > > >
> > > > > > NEW:
> > > > > >    In DOTS over TCP, heartbeat messages MUST be exchanged
> > > > > > between
> > > > the
> > > > > >    DOTS agents using the Ping and Pong messages specified in
> > > > > > Section
> > > 5.4
> > > > > >    of [RFC8323].  That is, the DOTS agent sends a Ping message
> > > > > > and
> > > the
> > > > > >    peer DOTS agent would respond by sending a single Pong
> message.
> > > The
> > > > > >    sender of a Ping message has to allow up to 'heartbeat-
> interval'
> > > > > >    seconds when waiting for a Pong reply.
> > > > >
> > > > > The last line does not look correct, the default
> > > > > heartbeat-interval is
> > > > > 30 seconds and the default user timeout is 5 minutes (TCP
> > > > > connection will be closed only after 5 minutes, see
> > > > > https://tools.ietf.org/html/rfc5482), 30 seconds looks aggressive
> > > > > to determine the connection is lost.
> > > > >
> > > >
> > > > [Med] This is a configurable parameter. When TCP is used, the server
> > > will
> > > > return the appropriate value to use.
> > >
> > > Yes, but 30 seconds of timeout looks too aggressive. I suggest we use
> > > 2 minutes (UDP uses 105 seconds) of heartbeat-interval.
> > >
> > > Cheers,
> > > -Tiru
> > >
> > > >
> > > > > Cheers,
> > > > > -Tiru
> > > > >
> > > > > >    When a failure is detected by
> > > > > >    a DOTS client, it proceeds with the session recovery
> > > > > > following
> > > the
> > > > > >    same approach as the one used for unreliable transports.
> > > > > >
> > > > > > Better?
> > > > > >
> > > > > > > Cheers,
> > > > > > > -Tiru
> > > > > > >
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > > Med
> > > > > > > >
> > > > > > > > > -----Message d'origine----- De : Valery Smyslov
> > > > > > > > > [mailto:valery@smyslov.net] Envoyé :
> > > > > > > > > samedi 20 juillet 2019 04:26 À : 'Konda, Tirumaleswar
> > > > > > > > > Reddy'; BOUCADAIR Mohamed TGI/OLN; 'Benjamin Kaduk';
> > > > > > > > > dots-chairs@ietf.org;
> > > > > > dots@ietf.org Objet :
> > > > > > > > > RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> > > > > > > > >
> > > > > > > > > Hi Tiru,
> > > > > > > > >
> > > > > > > > > thank you for clarification regarding TCP. It seems the
> > > > > > > > > this clarification somehow escaped from the discussion
> > > > > > > > > with Mirja (at least I cannot recall it was mentioned).
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Valery.
> > > > > > > > >
> > > > > > > > > > Hi Valery,
> > > > > > > > > >
> > > > > > > > > > The message transmission parameters including
> > > > > > > > > > missing-hb-allowed is only
> > > > > > > > > for
> > > > > > > > > > UDP transport (not for TCP). For the UDP, she is
> > > > > > > > > > suggesting us to go
> > > > > > > > > with a
> > > > > > > > > > mechanism that checks both side of the connectivity
> > > > > > > > > > using
> > > > > > > > > > non-
> > > > > > > > > confirmable
> > > > > > > > > > message with ping and pong at the application layer
> > > > > > > > > > instead of relying
> > > > > > > > > on the
> > > > > > > > > > CoAP ping/pong.
> > > > > > > > > >
> > > > > > > > > > Cheers,
> > > > > > > > > > -Tiru
> > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: Dots <dots-bounces@ietf.org> On Behalf Of Valery
> > > > > > > > > > > Smyslov
> > > > > > > > > > > Sent: Friday, July 19, 2019 5:13 PM
> > > > > > > > > > > To: mohamed.boucadair@orange.com; 'Benjamin Kaduk'
> > > > > > > > > > > <kaduk@mit.edu>du>; dots-chairs@ietf.org; dots@ietf.org
> > > > > > > > > > > Subject: Re: [Dots] Mirja's DISCUSS: Pending Point (AD
> > > > > > > > > > > Help
> > > > > > > > > > > Needed)
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Hi Med,
> > > > > > > > > > >
> > > > > > > > > > > I believe Mirja's main point was that if you use
> > > > > > > > > > > liveness check mechanism in the transport layer, then
> > > > > > > > > > > if it reports that liveness check fails, then it
> > > > > > > > > > > _also_ closes the transport
> > > > > session.
> > > > > > > > > > >
> > > > > > > > > > > Quotes from her emails:
> > > > > > > > > > > "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."
> > > > > > > > > > >
> > > > > > > > > > > and
> > > > > > > > > > >
> > > > > > > > > > > "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 close the
> > > > > connection."
> > > > > > > > > > >
> > > > > > > > > > > I'm not familiar with CoAP, but I suspect she's right
> > > > > > > > > > > about TCP - if TCP layer itself doesn't receive ACK
> > > > > > > > > > > for the sent data after several retransmissions, the
> > > connection is
> > > > closed.
> > > > > > > > > > >
> > > > > > > > > > > As far as I understand the current draft allows
> > > > > > > > > > > underlying liveness check to fail and has a parameter
> > > > > > > > > > > to restart this check several times if this happens.
> > > > > > > > > > > It seems that a new transport session will be created
> > > > > > > > > > > in this case (at least if TCP is used). In my reading
> > > > > > > > > > > of the draft this seems not been assumed, it is
> > > > > > > > > > > assumed that the session remains the same. So, I think
> > > > > > > > > > > that main Mirja's concern is that it won't work
> > > > > > > > > (at least
> > > > > > > > > > with TCP).
> > > > > > > > > > >
> > > > > > > > > > > I didn't participate in the WG discussion on this, so
> > > > > > > > > > > I don't know what was discussed regarding this issue.
> > > > > > > > > > > If it was discussed and the WG has come to conclusion
> > > > > > > > > > > that this is not an issue, then I believe more text
> > > > > > > > > > > should be added to the draft so, that people like
> > > > > > > > > > > Mirja, who didn't participate in the discussion, don't
> > > > > > > > > > > have any concerns while
> > > > > > > > > reading
> > > > > > > > > > the draft.
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > > Valery.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > From: mohamed.boucadair@orange.com
> > > > > > > > > > > > <mohamed.boucadair@orange.com>
> > > > > > > > > > > > Sent: Friday, July 19, 2019 9:57 AM
> > > > > > > > > > > > To: Benjamin Kaduk (kaduk@mit.edu) <kaduk@mit.edu>du>;
> > > > > > > > > > > > dots- chairs@ietf.org; dots@ietf.org
> > > > > > > > > > > > Subject: Mirja's DISCUSS: Pending Point (AD Help
> > > > > > > > > > > > Needed)
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Ben, chairs, all,
> > > > > > > > > > > >
> > > > > > > > > > > > (restricting the discussion to the AD/chairs/WG)
> > > > > > > > > > > >
> > > > > > > > > > > > * Status:
> > > > > > > > > > > >
> > > > > > > > > > > > All DISCUSS points from Mirja's review were fixed,
> > > > > > > > > > > > except the one discussed in this message.
> > > > > > > > > > > >
> > > > > > > > > > > > * Pending Point:
> > > > > > > > > > > >
> > > > > > > > > > > > Rather than going into much details, I consider the
> > > > > > > > > > > > following as the summary of the remaining DISCUSS
> > > > > > > > > > > > point from
> > > > > > Mirja:
> > > > > > > > > > > >
> > > > > > > > > > > > > I believe there are flaws in the design. First
> > > > > > > > > > > > > it’s a layer violation, but if more an idealistic
> > > > > > > > > > > > > concern but usually designing in layers is a good
> > > > > > > > > > > > > approach. But more importantly, you end up with
> > > > > > > > > > > > > un-frequent messages which may still terminate the
> > > > > > > > > > > > > connection at some point, while what you want is
> > > > > > > > > > > > > to simply send messages frequently in an
> > > > > > > > > > > > > unreliable fashion but a low rate until the
> > > > > > > > > attack is over.
> > > > > > > > > > > >
> > > > > > > > > > > > * Discussion:
> > > > > > > > > > > >
> > > > > > > > > > > > (1) First of all, let's remind that RFC7252 does not
> > > > > > > > > > > > define how CoAP ping must be used. It does only say:
> > > > > > > > > > > >
> > > > > > > > > > > > ==
> > > > > > > > > > > >       Provoking a Reset
> > > > > > > > > > > >       message (e.g., by sending an Empty Confirmable
> > > > > > > > > > > > message) is
> > > > > > > > > also
> > > > > > > > > > > >       useful as an inexpensive check of the liveness
> > > > > > > > > > > > of an
> > > > > > > endpoint
> > > > > > > > > > > >       ("CoAP ping").
> > > > > > > > > > > > ==
> > > > > > > > > > > >
> > > > > > > > > > > > How the liveness is assessed is left to
> applications.
> > > > > > > > > > > > So, there is
> > > > > > > > > > > > ** no layer violation **.
> > > > > > > > > > > >
> > > > > > > > > > > > (2) What we need isn't (text from Mirja):
> > > > > > > > > > > >
> > > > > > > > > > > > > to simply send messages frequently in an
> > > > > > > > > > > > > unreliable fashion but a low rate until the attack
> is over "
> > > > > > > > > > > >
> > > > > > > > > > > > It is actually the other way around. The spec says:
> > > > > > > > > > > >
> > > > > > > > > > > >   "... This is particularly useful for DOTS
> > > > > > > > > > > >    servers that might want to reduce heartbeat
> > > > > > > > > > > > frequency or
> > > > > > > cease
> > > > > > > > > > > >    heartbeat exchanges when an active DOTS client
> > > > > > > > > > > > has not
> > > > > > > requested
> > > > > > > > > > > >    mitigation."
> > > > > > > > > > > >
> > > > > > > > > > > > What we want can be formalized as:
> > > > > > > > > > > >  - Taking into account DDoS traffic conditions, a
> > > > > > > > > > > > check to assess the liveness of the peer DOTS agent
> > > > > > > > > > > > + maintain NAT/FW state on on-path
> > > > > > > > > > > devices.
> > > > > > > > > > > >
> > > > > > > > > > > > An much more elaborated version is documented in
> > > > > > > > > > > > SIG-004 of RFC
> > > > > > > > > 8612.
> > > > > > > > > > > >
> > > > > > > > > > > > * My analysis:
> > > > > > > > > > > >
> > > > > > > > > > > > - The intended functionality is naturally provided
> > > > > > > > > > > > by existing CoAP
> > > > > > > > > > > messages.
> > > > > > > > > > > > - Informed WG decision: The WG spent a lot of cycles
> > > > > > > > > > > > when specifying the current behavior to be meet the
> > > > > > > > > > > > requirements set
> > > > > > > in
> > > > > > > > RFC8612.
> > > > > > > > > > > > - Why not an alternative design: We can always
> > > > > > > > > > > > define messages with duplicated functionality, but
> > > > > > > > > > > > that is not a good design approach especially when
> > > > > > > > > > > > there is no evident
> > > > > benefit.
> > > > > > > > > > > > - The specification is not broken: it was
> > > > > > > > > > > > implemented and
> > > > > > > tested.
> > > > > > > > > > > >
> > > > > > > > > > > > And a logistic comment: this issue fits IMHO under
> > > > > > > > > > > > the non-discuss criteria in
> > > > > > > > > > > > https://www.ietf.org/blog/discuss-criteria-iesg-revi
> > > > > > > > > > > > ew/#
> > > > > > > > > > > > stan
> > > > > > > > > > > > d-
> > > > > > > > > > > undisc.
> > > > > > > > > > > >
> > > > > > > > > > > > * What's Next?
> > > > > > > > > > > >
> > > > > > > > > > > > As an editor, I don't think a change is needed but
> > > > > > > > > > > > I'd like to hear from Ben, chairs, and the WG.
> > > > > > > > > > > >
> > > > > > > > > > > > Please share your thoughts and whether you
> > > > > > > > > > > > agree/disagree with the above analysis.
> > > > > > > > > > > >
> > > > > > > > > > > > Cheers,
> > > > > > > > > > > > Med
> > > > > > > > > > >
> > > > > > > > > > >
> > _______________________________________________
> > > > > > > > > > > Dots mailing list
> > > > > > > > > > > Dots@ietf.org
> > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots
> > > > > >
> > > > > > _______________________________________________
> > > > > > Dots mailing list
> > > > > > Dots@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/dots