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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Mon, 22 July 2019 15:13 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 812451202FB for <dots@ietfa.amsl.com>; Mon, 22 Jul 2019 08:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, 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 CpXniWiT1jWB for <dots@ietfa.amsl.com>; Mon, 22 Jul 2019 08:13:42 -0700 (PDT)
Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.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 EE87B120362 for <dots@ietf.org>; Mon, 22 Jul 2019 08:13:36 -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=1563807741; 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=H I5g27/7QjLIVSwuVl4LaBy66wAYT4jpitFaU/v8dC g=; b=dMwKzZtf1O1FptFhJcDsXetNdBiyO9zTGRbsgKIlcROM RjWiVY4MqhTQ8Yp4kYUy51vxVzqKLK1Fw1fo+ZtOyevGXtonoL iEmPzneNxYKZhEjD5Iv/GiaIeq4JunfeO8vFNktJAi+dTs1mjp BPcAYj/n4oD6YFSd88WUAuywJBo=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-314-B75gb9LSMteAsuD4llLaOw-1; Mon, 22 Jul 2019 11:13:34 -0400
Received: from DNVEXAPP1N04.corpzone.internalzone.com (DNVEXAPP1N04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2998_a989_68ed8e9c_7901_4e9f_9120_5a3989ed9cdb; Mon, 22 Jul 2019 09:02:20 -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 09:13:31 -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 09:13:31 -0600
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Jul 2019 09:13:28 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y2wBlYOO3oH+X13TLVvw8/jrlIMcZ3R26dhUVLEHV6Q/9k8u0TuMYPLaoiHEe+dE0ZrjUMcvdrJiaKz6MPUK1eQQN0Jt6fQCL+DxyVy+c8sDJpbnqq1kbhCGToQW5UXQRsn2nWApiYKebHWQPAO05NZflJNK3tE5ScnIoW0HLpYnWOw77unJM+e4xXFFh4vPdWGtz0ba9ElotG67wJ7Da9nr6jd+RiJE+LckWTa/Vu0xOWAQzgr0nibyPikLWyj4IgdR7cHYV/gQWolJM6yC/KYh/rkoihq1NLsSzb9b7Q72kuobw991NEQH7EpbcsOQ4lNzxSBH1PdEy3WdEaig0Q==
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=HI5g27/7QjLIVSwuVl4LaBy66wAYT4jpitFaU/v8dCg=; b=IXNTuxzO51csxuCDHzzyTY6/HnP0kOhPHNwJHreiDY3qyZctzcZNXJ1uuVV5boR9PEVICBnuVgPPoEw4k7+gJEJZi7ww1rVU0KkU3cBNcC11p/oXwIWpwTV0Dx5vFEGesROvNjkkhc5x4z97EysRMXbXfZhUYaFI4uHyFSYNPJ8Fd28tkWcW04+SE7WyR1oYl3MZRIOyenwW/IbUtQunQ1UMRc+sLTa8vtWBSVeHwLmWfpkN8WJoUPDJ4B8TzPrZSoG6ZfLw3aTHRV/SzHm9fT4BxdIzfx5G62FI73ypWYfVgpnA/3NHhNDRHfToPMO0n00iMEDHXn+q55Vk8aYmtg==
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 DM5PR16MB2165.namprd16.prod.outlook.com (52.132.142.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.13; Mon, 22 Jul 2019 15:13:29 +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 15:13:29 +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+q90AABWUtgAAFZ9uAABONuAAAAWKWAAACgKrAAAmmhIAAAjoTQ
Date: Mon, 22 Jul 2019 15:13:29 +0000
Message-ID: <DM5PR16MB170574442C194A744F8EBD5CEAC40@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> <DM5PR16MB170553F3A8B1F3F1ED59D509EAC40@DM5PR16MB1705.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B9330312E3792@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <DM5PR16MB170505ABB7555E0ADCEC1BC6EAC40@DM5PR16MB1705.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B9330312E3A41@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312E3A41@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: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 26d0128d-1298-455b-bbc2-08d70eb72757
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB2165;
x-ms-traffictypediagnostic: DM5PR16MB2165:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <DM5PR16MB2165A26479CC2E0AE22F9052EAC40@DM5PR16MB2165.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01068D0A20
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(376002)(39850400004)(366004)(189003)(13464003)(51444003)(51914003)(199004)(32952001)(8936002)(2201001)(71190400001)(6116002)(6436002)(86362001)(8676002)(7696005)(966005)(68736007)(81166006)(33656002)(3846002)(6306002)(5660300002)(305945005)(25786009)(66476007)(53546011)(186003)(14454004)(76176011)(74316002)(81156014)(6506007)(66066001)(478600001)(102836004)(11346002)(476003)(2906002)(446003)(80792005)(66446008)(5024004)(66556008)(53946003)(2171002)(26005)(9686003)(2501003)(316002)(110136005)(30864003)(14444005)(53936002)(229853002)(7736002)(486006)(71200400001)(64756008)(76116006)(52536014)(55016002)(256004)(99286004)(66946007)(6246003)(85282002)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2165; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: f3QQ1Ead4jn5l0GghnaJp7OHVIMH4L9BHcf0diiV+zg1K4xEJKTbnauKnUeUo+hN/tEj7lym7GfasH97SCyLT2Mn5r2USA3lAZ2JV9gJ2CGW/DRQ/05+qDHYWVPCPEk1Icu8LD74Zkk32/ny6gPjlfuzKvFPhn9PywvuQWhXNwZtGVd0fLRmq4AOS0v2wHULzfHTtoxRYB/LyeqR71015N8PrD/NkYuU0QjdRg7i/iF0R4uOPFHUeJFAJUjojUH/vfTtOvuk0cPQXd+wo/6MUQ7qRUSUi7okyZGEjlTibVLLT6hqsIJ4jPOdbhPYUXByb4IXfryqB6W2h16iCH/3ODIcUvex8Fj1GA0LEbjB+PmZKxdQia9JLARhfgAYz/9BkIgO9JDR/wyDCH1ZDJOndlE8+IHrmgzGCBF4i8wrkTA=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 26d0128d-1298-455b-bbc2-08d70eb72757
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2019 15:13:29.6878 (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: DM5PR16MB2165
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 <1828103> : uri <2870864>
X-MC-Unique: B75gb9LSMteAsuD4llLaOw-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/ZZyl7VzBVNa4AlcWtECaU1jQkyk>
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 15:13:49 -0000

Got it, Thanks for the clarifications.

Cheers,
-Tiru

> -----Original Message-----
> From: mohamed.boucadair@orange.com
> <mohamed.boucadair@orange.com>
> Sent: Monday, July 22, 2019 8:33 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 16:02
> > À : 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 7:09 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-,
> > >
> > > > Yes, but 30 seconds of timeout looks too aggressive. I suggest we
> > > > use
> > > > 2 minutes (UDP uses 105 seconds) of heartbeat-interval.
> > >
> > > 30 seconds is recommended value for UDP (as this is our favorite
> > transport).
> >
> > I meant use 2 minutes for TCP (UDP heartbeat interval is 30 seconds,
> > and the timeout happens after 105 seconds).
> >
> 
> [Med] The reco we have for UDP was driven by NAT considerations. For TCP,
> why using 2 minutes is better than 5 minutes and so on? I'm afraid we don't
> have such argument. This is why I prefer to leave this deployment-specific.
> Please remember that using TCP as transport is not the recommended one.
> 
> > >
> > > If TCP is used, this falls into the following:
> > >
> > >       DOTS agents may
> > >       negotiate longer heartbeat-interval values to prevent any network
> > >       overload with too frequent keepalives.
> >
> > The above line is deployment specific not transport specific.
> 
> [Med] Deployment considerations cover transport ones.
> 
> > >
> > > Even if we include another recommended value for TCP, I'm afraid it
> > > is
> > not
> > > possible to reflect this in the YANG module:
> > >
> > >          leaf current-value {
> > >            type uint16;
> > >            units "seconds";
> > >            default "30";
> > >            description
> > >              "Current heartbeat-interval value.
> > >
> > >               '0' means that heartbeat mechanism is deactivated.";
> > >          }
> >
> > Yes, it is YANG limitation but not stop the protocol from giving a
> > recommendation for TCP.
> 
> [Med] The issue is that we need to be consistent: the parameter applies for
> all transport. We cannot set two defaults for it.
> 
> >
> > Cheers,
> > -Tiru
> >
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Konda, Tirumaleswar Reddy
> > > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > > Envoyé : lundi 22 juillet 2019 15:27 À : 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 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-
> > > > > > > > > > > > > revi
> > > > > > > > > > > > > ew/#
> > > > > > > > > > > > > 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