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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Mon, 22 July 2019 13:27 UTC

Return-Path: <tirumaleswarreddy_konda@mcafee.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 A9F921202F6 for <dots@ietfa.amsl.com>; Mon, 22 Jul 2019 06:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=neutral reason="invalid (public key: not available)" header.d=mcafee.com
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 rowN2i6xoOn5 for <dots@ietfa.amsl.com>; Mon, 22 Jul 2019 06:27:23 -0700 (PDT)
Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [216.205.24.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8B01202B5 for <dots@ietf.org>; Mon, 22 Jul 2019 06:27:22 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1563801365; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=P Jd5AnIDmUWNJ1tSQL8iGKkB8MkrviJowB8j7E/LH5 U=; b=kyiDQRGZKxMnjxoYmDfVmDyuKAqwryi19wO/ZDyzJjBX kwTDUg6mcKanSjxpewpQIDYi/Vqtqtgwjuk0LJAm2y4oqcnTVP pyi+y2zdpvEKvAGOpBkZlx45iTLBS/GaLpDuRLxDZER3C0I1k8 ykrfVsPaQQfktUKB61dzoVSc8AA=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-47-T6H_ucK1OSWcZJy_gqjYpA-1; Mon, 22 Jul 2019 09:27:18 -0400
Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2998_4d6e_cb3f3237_2afd_499a_8491_bf1915959459; Mon, 22 Jul 2019 07:16:04 -0600
Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Jul 2019 07:27:11 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 22 Jul 2019 07:27:11 -0600
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Jul 2019 07:27:08 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N1hvwzwxJyTGM9tddPTq93khzaGzTt5Xjcas9fz5zz6ovaaYNO58QhrIqPF9H7L9r0+8GJGv75E4TjH0n61Ctu80XmBxpS9i4TO9z695a7wLgEUDe7xCdT5k8NnanSv7oPl6tjS/1vc2+IXrEgsgZZRWIj1pGfs+ON+iV75F3Tgoz0yTxjEa3riiuho4tUNTi1oLXas4l1sCjlHQ26eImG0fOg0BNfj1MbqHWqaaEuELwvB2ZCuhu1PZPgy5RlK+pu04BjLcl4PLFsonaL2IhdnejWU4R4mrYu3Dtzr20M0ODzZpei/8MQUznSGM7800msSoQPzjafcvPYKFb1DVkw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PJd5AnIDmUWNJ1tSQL8iGKkB8MkrviJowB8j7E/LH5U=; b=KInz2k/C5mlUw2/sNf9mzxJ+euDp4O5vhpaNdm2HrVOm2NOzi8wvsAVZAgjQY5TIn2QlHw76mV0s+lNxbNpeKX8WIfBAOKjfChagwDwt6A5E3fHbyql9bdz/AunrSpGgJAelwHXbPsAoGPFsYKi2Zl1WkB5v+1/EOfvoY+GxRRDkwtwL68VAHtp/fr3g9Adhw44Se2iHcaeBLKpO9sFpYdtfQkA1CxLSOaY7c683Dqkn+3bxAsGHuvvdVPdMfCLo/SyX6ZuOZek46RNBdde+b1dWmUpfFFM4pmn9Djx1g/+FDzeUjEbtbGUh/opnkuYW/OJvpHyVxOfHnAdl2yGsbA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none
Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB2247.namprd16.prod.outlook.com (52.132.142.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Mon, 22 Jul 2019 13:27:08 +0000
Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2094.013; Mon, 22 Jul 2019 13:27:08 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.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+q90AABWUtgAAFZ9uAABONuAA==
Date: Mon, 22 Jul 2019 13:27:08 +0000
Message-ID: <DM5PR16MB170553F3A8B1F3F1ED59D509EAC40@DM5PR16MB1705.namprd16.prod.outlook.com>
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> <787AE7BB302AE849A7480A190F8B9330312E34A0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312E34A0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.3.0.16
dlp-reaction: no-action
x-originating-ip: [49.37.200.50]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 27c749b8-4526-4fb6-4179-08d70ea84baa
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB2247;
x-ms-traffictypediagnostic: DM5PR16MB2247:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <DM5PR16MB224758220DD3D50FB8B2C158EAC40@DM5PR16MB2247.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01068D0A20
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(39860400002)(346002)(136003)(376002)(32952001)(13464003)(51444003)(199004)(189003)(14454004)(486006)(6436002)(74316002)(99286004)(256004)(446003)(53946003)(53936002)(110136005)(14444005)(6306002)(9686003)(305945005)(5024004)(3846002)(6116002)(8676002)(478600001)(55016002)(11346002)(25786009)(7736002)(2201001)(316002)(8936002)(66066001)(476003)(86362001)(966005)(26005)(33656002)(6506007)(5660300002)(71200400001)(102836004)(71190400001)(66946007)(186003)(76176011)(68736007)(52536014)(66476007)(64756008)(66446008)(66556008)(76116006)(2501003)(7696005)(53546011)(81156014)(81166006)(2906002)(30864003)(2171002)(80792005)(229853002)(6246003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2247; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: UJFT3cpm2LYtQ9cVx4+dAGN6Fqs0H7S+jZQXk9I7YEOkDYCRMDQRWMMmQLC58JsFickczlJRXETg3Hx+dbp86oDi8p5RnuBcPgTC4GTU+67CF7wlTnJQMU7ORA2yDD5iXjVzNZC48ku8J832tSdHQOqyLoS4CliYXsB2dL9MVR3AdA9djrRrazywY7TbXdElpbOyxWyxXUajGFaNR6WBuGrSC7QBihC9+NKFr313cA1sf8gR6cUvWnz4TQCH4+vAmlQ3C2rluXCywPrNIMfOdDoYkq6KA24hdII6g6lo+EkkRmTWBX1yeyWGpfkdrJG9l4LLh85gsn+318Llyix7UQE9D9Ki3TctJgi06unTz178sFGcucjhbFgKEo5W0j7oXE7356CfwSxJc5Ki2mO5Fh3F/Sh0xHZNkwxUslvSl+k=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 27c749b8-4526-4fb6-4179-08d70ea84baa
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2019 13:27:08.0816 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2247
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0
X-NAI-Spam-Version: 2.3.0.9418 : core <6595> : inlines <7122> : streams <1828095> : uri <2870827>
X-MC-Unique: T6H_ucK1OSWcZJy_gqjYpA-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/kTYxEybQ20spvnIZ-CkL5rTPvDA>
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 13:27:32 -0000

> -----Original Message-----
> From: mohamed.boucadair@orange.com
> <mohamed.boucadair@orange.com>
> Sent: Monday, July 22, 2019 4:32 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)
> 
> 
> 
> 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.

Yes, but 30 seconds of timeout looks too aggressive. I suggest we use 2 minutes (UDP uses 105 seconds) of heartbeat-interval.

Cheers,
-Tiru

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