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>om>; Valery Smyslov
> > <valery@smyslov.net>et>; 'Benjamin Kaduk' <kaduk@mit.edu>du>; 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>et>; Konda, Tirumaleswar Reddy
> > > > <TirumaleswarReddy_Konda@McAfee.com>om>; 'Benjamin Kaduk'
> > > > <kaduk@mit.edu>du>; 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>du>; 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>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/#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