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

"Valery Smyslov" <valery@smyslov.net> Fri, 19 July 2019 11:42 UTC

Return-Path: <valery@smyslov.net>
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 5F3D112017C; Fri, 19 Jul 2019 04:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.335
X-Spam-Level: *
X-Spam-Status: No, score=1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net
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 d5Lbxv9iUUQB; Fri, 19 Jul 2019 04:42:55 -0700 (PDT)
Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67EF6120019; Fri, 19 Jul 2019 04:42:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=V336Rnbqz9WoamiqbGHrHIyfxhOLRIHsqSEvk6pSLD8=; b=1Srq0BPl2htFsLERWmeniRNFNI PZKUa0Fox4w5c6s+v+52f6oy7TJ/t5PND/C3QvbjJVfkh2mLe3UAcPANFnrBB7jT+V+7l8z2f6cE2 JAvQfgJjwCCex9uDXjWm871i2l/J0Lbw6Es4RjD+aTox1O6UHzvVZSVNURUSlK4sXjhqeKyo+QGZM T6cxfpm5rvOYud+ylh5olPZD/60J6J34xFtJtnJkPC8X7VyQhjpj5bGFmEeLz7g5Dkg4iCbTXQ9Am 9ohj3f0uUtNmVJLjq5Ze8uuYJFSkaLlctKBuwghMN9sIDXEK8PdRLK/U42ypNUK9CGi/SI7aGdEFW i6QeiZAg==;
Received: from [89.248.140.13] (port=51384 helo=svannotebook) by direct.host-care.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <valery@smyslov.net>) id 1hoRHp-0000Hg-43; Fri, 19 Jul 2019 07:42:53 -0400
From: "Valery Smyslov" <valery@smyslov.net>
To: <mohamed.boucadair@orange.com>, "'Benjamin Kaduk'" <kaduk@mit.edu>, <dots-chairs@ietf.org>, <dots@ietf.org>
References: <787AE7BB302AE849A7480A190F8B93302FA841A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302FA841A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Fri, 19 Jul 2019 14:42:50 +0300
Message-ID: <00c201d53e27$194cfc20$4be6f460$@smyslov.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQI3NMpmTxo3A+0PVQS1r9HIn/ZDyqYN3R5g
Content-Language: ru
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - direct.host-care.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - smyslov.net
X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net
X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/HPLlpd5-l5IYda91b8wGaRyh7IY>
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 11:42:58 -0000

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-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