Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
<mohamed.boucadair@orange.com> Mon, 22 July 2019 11:01 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 4CD94120130; Mon, 22 Jul 2019 04:01:40 -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 oH7RULwbpz-L; Mon, 22 Jul 2019 04:01:38 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F5A120058; Mon, 22 Jul 2019 04:01:37 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 45sdw02Vx0z2xNG; Mon, 22 Jul 2019 13:01:36 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 45sdw01CH9z1xpK; Mon, 22 Jul 2019 13:01:36 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Mon, 22 Jul 2019 13:01:35 +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+q90AABWUtgAAFZ9uA=
Date: Mon, 22 Jul 2019 11:01:35 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330312E34A0@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>
In-Reply-To: <DM5PR16MB1705DFCE2F9B379A36FD79AAEAC40@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.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/ThdqrXZFMbkhWj0e2KCE5wan4fw>
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 11:01:41 -0000
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>; Valery Smyslov > > <valery@smyslov.net>; 'Benjamin Kaduk' <kaduk@mit.edu>; 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>; Konda, Tirumaleswar Reddy > > > > <TirumaleswarReddy_Konda@McAfee.com>; 'Benjamin Kaduk' > > > > <kaduk@mit.edu>; 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. > 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>; 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/#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
- [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