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

<mohamed.boucadair@orange.com> Fri, 19 July 2019 06:57 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E63BA1200C1; Thu, 18 Jul 2019 23:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DYJ3Lkv4obaB; Thu, 18 Jul 2019 23:57:25 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E5261200B7; Thu, 18 Jul 2019 23:57:25 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 45qhdb5Hv6zFr15; Fri, 19 Jul 2019 08:57:23 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 45qhdb4MlQzBrLs; Fri, 19 Jul 2019 08:57:23 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM41.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Fri, 19 Jul 2019 08:57:23 +0200
From: <mohamed.boucadair@orange.com>
To: "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/zWZw7DhsbF6RNCA2PYrEJMCCA==
Date: Fri, 19 Jul 2019 06:57:23 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302FA841A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/z2XwD5bdiigSidLoiyiHwzuP9vk>
Subject: [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 06:57:28 -0000

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

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.