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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Fri, 19 July 2019 12:35 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 C8F10120150 for <dots@ietfa.amsl.com>; Fri, 19 Jul 2019 05:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" 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 mjmwBp6zYvGF for <dots@ietfa.amsl.com>; Fri, 19 Jul 2019 05:35:44 -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 651B31200BA for <dots@ietf.org>; Fri, 19 Jul 2019 05:35:44 -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=1563539077; 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-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=4mYBs0n8Mf3FJRh0gM+2PDgAVF9firoqb2Dc2q Q1VLI=; b=Qk1r9W2TZb3RB4tA8YCQdOaceYh/2rsmP1vbmKOk 5KIR6nDXpl0n5afVgP8kphaWJF7czsuqPLU15x4p1+opJBEBj/ 75g38fGC8D37ksnKCfWZ5JYsMfv9KY+i15SaHyTrV7NYs/fKwd yGeg/Aqxlh7PvL6AopCVrrzVIupz4vA=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-105-SfzfmjpaMdSjOhJyrp6Wnw-1; Fri, 19 Jul 2019 08:35:40 -0400
Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6f0d_2218_f74a3106_447d_4391_9d6a_9d1dba8f98fc; Fri, 19 Jul 2019 06:24:36 -0600
Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 19 Jul 2019 06:35:36 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 19 Jul 2019 06:35:36 -0600
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 19 Jul 2019 06:35:35 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hlcr1s84MbgL2odLi1OG+u9UqBkEeYpUiB3y8rXDCEQcFpD/oYDmINIIssTDltAxvB41oIyl2BrL04OYz9iHUt5OKMy9zd6714IKBKMGW+6hbETRiVuiMvuem6AWGCi8//+e9HbGViq+dt0+7Pdt/j+br1+oc2U2IMUjVHwVrpbvaPKf9SbRw72V7do9dRtNRtcZtSR7LvxzOGsbS+/2s34y8+T0fRA3m3AjbJTeSPhrmVDuzyDXHPpZaUBbvEQ02vRIjJK0bXVnNEbqYO2l5SkTM6tOFmxOu0l2wUg13i7iyBggOiijnVPJKyKdkwAmSZ98CMpMgdxf5nwDvU2Yag==
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=4mYBs0n8Mf3FJRh0gM+2PDgAVF9firoqb2Dc2qQ1VLI=; b=NgTA2NCC55H3ofS1Ea9sNEgLrYjlrwUb+oGFfV/RphcUeMgmyhJyAW7233+JFzA2gWJBVz6TeQyTs5hmgje9/mfKScyUpdvGSFG5oxSM1ednGRC5Bu+ZZDIojMMP7kS3s6gtWMFpIPilD4lgy2Ri4MDEQwUZ3pTrI2YbV9uOzpZeC4cR/ClE8is8+ef1/+jPfYgaKQJ6pTyLBPQPXtj3mrw/vuSunJq7wvl+ORK7BvGY3esK9OYMyJ9i4If9sUMONL91LoFeG01odu2ZDXdrxIW4KdcXCE39O8+aNUM0jd6jyOkkqIdwc8Dd53cWzf4uU/8X0rVME9tW6gU6nqq0eg==
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 DM5PR16MB1449.namprd16.prod.outlook.com (10.173.215.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Fri, 19 Jul 2019 12:35:35 +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.2073.012; Fri, 19 Jul 2019 12:35:35 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Benjamin Kaduk (kaduk@mit.edu)" <kaduk@mit.edu>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: Mirja's DISCUSS: Pending Point (AD Help Needed)
Thread-Index: AdU9/zWZw7DhsbF6RNCA2PYrEJMCCAALa6Og
Date: Fri, 19 Jul 2019 12:35:35 +0000
Message-ID: <DM5PR16MB170566EAA36BC8CF08A8B92AEACB0@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <787AE7BB302AE849A7480A190F8B93302FA841A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302FA841A9@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.206.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: df306485-ff0d-4e39-87af-08d70c4598da
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1449;
x-ms-traffictypediagnostic: DM5PR16MB1449:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <DM5PR16MB14494A6BBB7DE6B2550D275BEACB0@DM5PR16MB1449.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01039C93E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(39860400002)(346002)(136003)(366004)(32952001)(13464003)(199004)(189003)(66946007)(66556008)(68736007)(66446008)(76116006)(14454004)(64756008)(25786009)(102836004)(316002)(52536014)(7696005)(76176011)(5660300002)(26005)(66066001)(186003)(6116002)(3846002)(8676002)(53546011)(229853002)(80792005)(2201001)(966005)(33656002)(2501003)(2906002)(6506007)(71200400001)(6436002)(55016002)(86362001)(81156014)(99286004)(486006)(478600001)(14444005)(8936002)(256004)(6246003)(476003)(2171002)(66476007)(9686003)(6306002)(81166006)(11346002)(110136005)(446003)(74316002)(305945005)(53936002)(71190400001)(7736002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1449; 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: mQWwJWTQXfMQQ/FQyJfpG/G1WVXcSBxWAnjjeg0+EUXOI6vlP+4ntwAz+QvYaVwrx6tsq+mtt0zWHDHKPwulu0mpLy5tbmnChONUh4Hc/xxiZJQz/dgIr15FyEe+NrCYEjcFkR5mx1vAye89PTpkF6h06R7Un09pGyjHFBB7k5a5hZalxFON8I/B/n4nEubpNg7mwB4g+3vMUpxIhIy7KZw/2tlbus6+zLF1VqmxXlozM87y17yYGWXfA+949AY8YRDKPq8cOJ5N85dK7ymDVdla2DjMUoIjMowWnev1M98EEBMPywmRy1QxVpXM2qWg//fqGgf5iqqp2JeyiNQ68HSotA+nKt6HB2eWp1CxNZbcPAFfvGVSKIi+kZ+7x9d9HfVYA764xj8z8mwSa9e7sSbfGKzxHtR3Zl+XOXrU3cA=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: df306485-ff0d-4e39-87af-08d70c4598da
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2019 12:35:35.1608 (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: DM5PR16MB1449
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.1
X-NAI-Spam-Version: 2.3.0.9418 : core <6593> : inlines <7120> : streams <1827805> : uri <2869314>
X-MC-Unique: SfzfmjpaMdSjOhJyrp6Wnw-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/QRMfsmhPTFksN6a_nBBKimVx-lM>
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: Fri, 19 Jul 2019 12:35:47 -0000

Hi Med,

I agree with all your responses except the alternate design is a duplicate functionality. The alternate design proposed by her to use non-confirmable message with ping and pong at the application layer itself will not work in the first place.
The client can perform application level ping/pong (e.g. GET /heartbeat) but the server cannot perform application level ping/ping. The server cannot send non-confirmable requests or empty messages to the client.

1) As per RFC7252, client can only send requests, and the server can only send responses.
2) (Section 4.3 in RFC7252) A Non-confirmable message always carries either a request or response and MUST NOT be Empty.  A Non-confirmable message MUST NOT be acknowledged by the recipient.
3) (Section 4.3 in RFC7252) Rejecting a Non-confirmable message MAY involve sending a matching Reset message, and apart from the Reset message the rejected message MUST be silently ignored.

1), 2) and 3) make non-confirmable ping at the application layer from server impossible to use.

Cheers,
-Tiru


> -----Original Message-----
> From: Dots <dots-bounces@ietf.org> On Behalf Of
> mohamed.boucadair@orange.com
> Sent: Friday, July 19, 2019 12:27 PM
> To: Benjamin Kaduk (kaduk@mit.edu) <kaduk@mit.edu>du>; dots-
> chairs@ietf.org; dots@ietf.org
> Subject: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> 
> 
> 
> Hi Ben, chairs, all,
> 
> (restricting the discussion to the AD/chairs/WG)
> 
> * Status:
> 
> All DISCUSS points from Mirja's review were fixed, except the one discussed
> in this message.
> 
> * Pending Point:
> 
> Rather than going into much details, I consider the following as the summary
> of the remaining DISCUSS point from Mirja:
> 
> > I believe there are flaws in the design. First it’s a layer violation,
> > but if more an idealistic concern but usually designing in layers is a
> > good approach. But more importantly, you end up with un-frequent
> > messages which may still terminate the connection at some point, while
> > what you want is to simply send messages frequently in an unreliable
> > fashion but a low rate until the attack is over.
> 
> * Discussion:
> 
> (1) First of all, let's remind that RFC7252 does not define how CoAP ping must
> be used. It does only say:
> 
> ==
>       Provoking a Reset
>       message (e.g., by sending an Empty Confirmable message) is also
>       useful as an inexpensive check of the liveness of an endpoint
>       ("CoAP ping").
> ==
> 
> How the liveness is assessed is left to applications. So, there is ** no layer
> violation **.
> 
> (2) What we need isn't (text from Mirja):
> 
> > to simply send messages frequently in an unreliable fashion but a low
> > rate until the attack is over "
> 
> It is actually the other way around. The spec says:
> 
>   "... This is particularly useful for DOTS
>    servers that might want to reduce heartbeat frequency or cease
>    heartbeat exchanges when an active DOTS client has not requested
>    mitigation."
> 
> What we want can be formalized as:
>  - Taking into account DDoS traffic conditions, a check to assess the liveness
> of the peer DOTS agent + maintain NAT/FW state on on-path devices.
> 
> An much more elaborated version is documented in SIG-004 of RFC 8612.
> 
> * My analysis:
> 
> - The intended functionality is naturally provided by existing CoAP messages.
> - Informed WG decision: The WG spent a lot of cycles when specifying the
> current behavior to be meet the requirements set in RFC8612.
> - Why not an alternative design: We can always define messages with
> duplicated functionality, but that is not a good design approach especially
> when there is no evident benefit.
> - The specification is not broken: it was implemented and tested.
> 
> And a logistic comment: this issue fits IMHO under the non-discuss criteria in
> https://www.ietf.org/blog/discuss-criteria-iesg-review/#stand-undisc.
> 
> * What's Next?
> 
> As an editor, I don't think a change is needed but I'd like to hear from Ben,
> chairs, and the WG.
> 
> Please share your thoughts and whether you agree/disagree with the above
> analysis.
> 
> Cheers,
> Med
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots