Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
"Valery Smyslov" <valery@smyslov.net> Sat, 20 July 2019 02:26 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 40D031200E9; Fri, 19 Jul 2019 19:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 WTkDiX-PVB7u; Fri, 19 Jul 2019 19:25:58 -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 76FE6120130; Fri, 19 Jul 2019 19:25:58 -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=GSsMb+cgbWdnA6A/SzfFGAczz3ITcbjmN/s2W87A/aY=; b=Pjfr6UEcKDCbqPIeZjOxcO8bJF t3yQ+RsyzoaOH0B+FFFP9o7foKG/L7dMQPslSwCBj/g4GePQ1DqJQKggxJDXpHpReaI/h0MWhmNa8 cYnDNzCX4Y351g88f9PmtJoRMoqyUNQaB0FSVxne5GwC1kyzDhyb5ImgAjzENpO/Dptk7Lyab+xRd KKHcgabGmgLPTDxvs7h6iDowRiYKXApW+wuFRlrEHE7nna97+qUcuFdTvNNGYjlb2KwH0ihtnpLoZ 4K74H4POlTBfy2MDTl9xw25rAKi8vj7vewRun7w0MBUJI5B92O+nbhzeknPd2W8hiqhSWkx5XUIYW 2AnYsRig==;
Received: from modemcable142.183-83-70.mc.videotron.ca ([70.83.183.142]:51568 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 1hof4N-0001Kq-9y; Fri, 19 Jul 2019 22:25:55 -0400
From: Valery Smyslov <valery@smyslov.net>
To: "'Konda, Tirumaleswar Reddy'" <TirumaleswarReddy_Konda@McAfee.com>, mohamed.boucadair@orange.com, 'Benjamin Kaduk' <kaduk@mit.edu>, dots-chairs@ietf.org, dots@ietf.org
References: <787AE7BB302AE849A7480A190F8B93302FA841A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <00c201d53e27$194cfc20$4be6f460$@smyslov.net> <DM5PR16MB1705B5FC8E9204012E34636FEACB0@DM5PR16MB1705.namprd16.prod.outlook.com>
In-Reply-To: <DM5PR16MB1705B5FC8E9204012E34636FEACB0@DM5PR16MB1705.namprd16.prod.outlook.com>
Date: Sat, 20 Jul 2019 05:25:53 +0300
Message-ID: <011701d53ea2$74d81540$5e883fc0$@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/ZDygFLQw4RAblfkIil9rStEA==
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/a6UqaCYD7LClpS_kYV9l-3PT6bU>
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: Sat, 20 Jul 2019 02:26:01 -0000
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>; > > 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>; 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 > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots
- [Dots] Mirja's DISCUSS: Pending Point (AD Help Ne… mohamed.boucadair
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… Jon Shallow
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… Valery Smyslov
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… Konda, Tirumaleswar Reddy
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… Konda, Tirumaleswar Reddy
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… mohamed.boucadair
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… Valery Smyslov
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… Benjamin Kaduk
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… Konda, Tirumaleswar Reddy
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… mohamed.boucadair
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… Konda, Tirumaleswar Reddy
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… mohamed.boucadair
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… Konda, Tirumaleswar Reddy
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… mohamed.boucadair
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… Konda, Tirumaleswar Reddy
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… mohamed.boucadair
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… Konda, Tirumaleswar Reddy
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… mohamed.boucadair
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… Konda, Tirumaleswar Reddy
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… mohamed.boucadair
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… Konda, Tirumaleswar Reddy
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… mohamed.boucadair
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… kaname nishizuka
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… Benjamin Kaduk
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… mohamed.boucadair
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… Benjamin Kaduk
- Re: [Dots] Mirja's DISCUSS: Pending Point (AD Hel… mohamed.boucadair
- [Dots] FW: Mirja's DISCUSS: Pending Point (AD Hel… Valery Smyslov