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

<mohamed.boucadair@orange.com> Fri, 19 July 2019 13:02 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 7EA5E12018B; Fri, 19 Jul 2019 06:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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] 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 hxuRw9AMLgDt; Fri, 19 Jul 2019 06:02:57 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2808912012A; Fri, 19 Jul 2019 06:02:57 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 45qrlM20lFz4wlf; Fri, 19 Jul 2019 15:02:55 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 45qrlM1Qk8z8sY1; Fri, 19 Jul 2019 15:02:55 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6C.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Fri, 19 Jul 2019 15:02:55 +0200
From: <mohamed.boucadair@orange.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, "Benjamin Kaduk (kaduk@mit.edu)" <kaduk@mit.edu>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: Mirja's DISCUSS: Pending Point (AD Help Needed)
Thread-Index: AdU9/zWZTxo3A+0PVQS1r9HIn/ZDygALa6OgAACDRPA=
Date: Fri, 19 Jul 2019 13:02:54 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302FA8552E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B93302FA841A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <DM5PR16MB170566EAA36BC8CF08A8B92AEACB0@DM5PR16MB1705.namprd16.prod.outlook.com>
In-Reply-To: <DM5PR16MB170566EAA36BC8CF08A8B92AEACB0@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/8hiFQgDOexkh3B3KvlyNnG0qbcI>
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: Fri, 19 Jul 2019 13:03:00 -0000

Re-,

Good point. A server can only send an empty confirmable message. 

This concludes there is no alternate approach. 

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
> Envoyé : vendredi 19 juillet 2019 14:36
> À : BOUCADAIR Mohamed TGI/OLN; Benjamin Kaduk (kaduk@mit.edu); dots-
> chairs@ietf.org; dots@ietf.org
> Objet : RE: Mirja's DISCUSS: Pending Point (AD Help Needed)
> 
> Hi Med,
> 
> I agree with all your responses except the alternate design is a duplicate
> functionality. The alternate design proposed by her to use non-confirmable
> message with ping and pong at the application layer itself will not work
> in the first place.
> The client can perform application level ping/pong (e.g. GET /heartbeat)
> but the server cannot perform application level ping/ping. The server
> cannot send non-confirmable requests or empty messages to the client.
> 
> 1) As per RFC7252, client can only send requests, and the server can only
> send responses.
> 2) (Section 4.3 in RFC7252) A Non-confirmable message always carries
> either a request or response and MUST NOT be Empty.  A Non-confirmable
> message MUST NOT be acknowledged by the recipient.
> 3) (Section 4.3 in RFC7252) Rejecting a Non-confirmable message MAY
> involve sending a matching Reset message, and apart from the Reset message
> the rejected message MUST be silently ignored.
> 
> 1), 2) and 3) make non-confirmable ping at the application layer from
> server impossible to use.
> 
> Cheers,
> -Tiru
> 
> 
> > -----Original Message-----
> > From: Dots <dots-bounces@ietf.org> On Behalf Of
> > mohamed.boucadair@orange.com
> > Sent: Friday, July 19, 2019 12:27 PM
> > To: Benjamin Kaduk (kaduk@mit.edu) <kaduk@mit.edu>du>; dots-
> > chairs@ietf.org; dots@ietf.org
> > Subject: [Dots] 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-review/#stand-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