IETF Logo Mail Archive

Re: [Dots] Data Channel - Deletion of Aliases when manually configured on DOTS Server

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Wed, 05 September 2018 13:01 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 01148128D0C for <dots@ietfa.amsl.com>; Wed, 5 Sep 2018 06:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 omCRs_CnEOZR for <dots@ietfa.amsl.com>; Wed, 5 Sep 2018 06:01:27 -0700 (PDT)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45289128D68 for <dots@ietf.org>; Wed, 5 Sep 2018 06:01:27 -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=1536152497; h=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-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-ms-exchange-senderadcheck:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-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=fcY7PrOyIRRNhxOd9wv8baKo97ztdvEffaNLGF gCLCg=; b=l5avDYTpUvtDbLdCyyu3dXstGwhsMHtKAOS5pfKQ 9D9IQN4jmmcAzU5JEN2BVek7qHCkKy9XSL7GaBsCPpe4sHFGQq sn5IN8K47Rahmjnn5YCoVV9viVm8Kph0gro4siN24PuiKKPYX9 /44zI2CrX0KrMdG3z3PFSSTOLEpLrLU=
Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 18d3_8883_69d94f98_d655_4b0e_8504_733dc6b9771f; Wed, 05 Sep 2018 08:01:37 -0500
Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 5 Sep 2018 07:01:25 -0600
Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 5 Sep 2018 07:01:24 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 5 Sep 2018 07:01:24 -0600
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 5 Sep 2018 07:01:23 -0600
Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1491.namprd16.prod.outlook.com (10.172.207.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1101.17; Wed, 5 Sep 2018 13:01:22 +0000
Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::a14e:458f:4a71:ef35]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::a14e:458f:4a71:ef35%6]) with mapi id 15.20.1101.016; Wed, 5 Sep 2018 13:01:22 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Jon Shallow <supjps-ietf@jpshallow.com>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] Data Channel - Deletion of Aliases when manually configured on DOTS Server
Thread-Index: AdRFAu54VN0AjTquSDWy2o8cWBv6OwAAL20gAANB7AAAAP15oA==
Date: Wed, 05 Sep 2018 13:01:22 +0000
Message-ID: <BN6PR16MB1425DA13BFE5767CAA90D578EA020@BN6PR16MB1425.namprd16.prod.outlook.com>
References: <006401d44502$eedc4090$cc94c1b0$@jpshallow.com> <BN6PR16MB14255336A8BCE46C9BBAD404EA020@BN6PR16MB1425.namprd16.prod.outlook.com> <009c01d44510$b4f81ee0$1ee85ca0$@jpshallow.com>
In-Reply-To: <009c01d44510$b4f81ee0$1ee85ca0$@jpshallow.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.0.500.52
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [122.172.91.201]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR16MB1491; 6:nIS/0/XyY7MZOywwPtOt4iQqiraW65YUTsLCk18FSOdoag8rmFW+eFubp1qOVQDSUCbDWlHqKvuhWx6a2/+hIA6QjJosTcwSpCmg/Hn4SA0Z5KVXv+lLf10aHthgzgquQcZJhHW3Sv3IMLY0Lje5gI7HpMSCZJRsCzSssIPBisvtCjObAEczZFZGf1uuh8KJY9BXtlX4pE79SekC6gsiZ0ImjHqiVSwnUsBCb12ppswPpBWtEY0YtueIXa/3uYHx8MhO25409f0SN/7q8F6bmJZY9NUryaEu99YNeIIH1W9hbwAmma9GlJ6xaNwQCiGJ8kISkng6zVUrCuy2eFqOda4sAfnnBcG4904j3nFWgLdYAMh+o2trbW86L0ECay8kwkg/5t/lXXhzhzc/QaQUa4J4ZdWsMawVSQhAQw4j1cp2dfkPx4A4zQGwAGm0erSIq42R3VZspLrPGYT5maIG5w==; 5:WqrF/+SULvxDa08MFhi4pAtZeOsD1Y0YHN3YR/KAJ0Gk5yzVJBr6AafojXWXvTLhjcKejtvlqlJOvivDArP3iv09m+U4HODlu0m9n58H6e5tp1ejxz5hbLaHXrSnj4HYzMzcRuyyQZbkj5gLPY+U2jGgKx8A7trmI/BIatm0SQ4=; 7:erozEtMhk5ZJY5m3Jo/V7BmN+j7NpPvsBy094JwjWEFEMAlAJquHdT37BHgeFBvJgviI7/T+o3FTEHJNhMcsRQTxbTjt6ZjxYshmeQXiaXq1K/2fOGfB4NQDhLOWfMbf1ncaKg2DMcz0XNSCyBAWimdRByeToKHbU2hQD+pfvzR8rzP0QFk3gFwava62Dp/HwNOjjUoj/gjQYZHvk8k3XJDgH90nph59q2/Or4KgM0nvqvhe7BLcVAyl8JeF2HeC
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 918d6c19-6ed8-4b49-451a-08d6132fae5f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1491;
x-ms-traffictypediagnostic: BN6PR16MB1491:
x-microsoft-antispam-prvs: <BN6PR16MB14912D705679D8BC98996025EA020@BN6PR16MB1491.namprd16.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(103651359005742)(21748063052155)(123452027830198);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201708071742011)(7699016); SRVR:BN6PR16MB1491; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1491;
x-forefront-prvs: 078693968A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(376002)(346002)(366004)(136003)(32952001)(199004)(189003)(97736004)(9326002)(33656002)(81166006)(8936002)(86362001)(6246003)(72206003)(2900100001)(2501003)(7736002)(478600001)(5660300001)(14454004)(66066001)(5250100002)(6436002)(8676002)(790700001)(6116002)(25786009)(3846002)(54896002)(6306002)(81156014)(55016002)(74316002)(11346002)(476003)(316002)(446003)(110136005)(486006)(99286004)(102836004)(26005)(105586002)(236005)(68736007)(186003)(7696005)(53936002)(9686003)(80792005)(2906002)(229853002)(5024004)(256004)(106356001)(14444005)(53546011)(19609705001)(6506007)(76176011)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1491; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: lrsuAGeeO4NFtGhFk4c1lBHC9J/QJE/8MShaciNqp2lB5lPqWBOq/BzF9XgrOudmLjRE/rJDs6FmJ+T16DZGcBwYvuwJZpX29Eu5/PoqeviS5c59/I7Vb+BCGu5TgLNSE0M4ZPWFRoa/knQrKsY3z2zkW267AeHbe2JhKiO5nPdBI0WCZRjkRyaHLW6387wt5cJrJDESynzEPZh9VOavOyRB+4DsoHLYeBa8mI2YyPHoQwL6kSVvWa0ZTGF9jyr94qru/urkNSQB5KqtKyZ414d0CgOi1sEbIS9nsAnni3/HWHzp1mLYpjlFAIs5FF5wB6GAed5MKWlOiPkSsnWPwIuyw2kDVBe7GD81REKLH1Q=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1425DA13BFE5767CAA90D578EA020BN6PR16MB1425namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 918d6c19-6ed8-4b49-451a-08d6132fae5f
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2018 13:01:22.8773 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1491
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 <6367> : inlines <6854> : streams <1797568> : uri <2703572>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/8eSnJPf-6XrvXXkwXeDoPvfOXX8>
Subject: Re: [Dots] Data Channel - Deletion of Aliases when manually configured on DOTS Server
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: Wed, 05 Sep 2018 13:01:31 -0000

Hi Jon,

It looks like an oversight to me. If multiple modes of configuration is supported for aliases, it’s a troubleshooting nightmare, could lead to race condition and inconsistent configuration, and as you know one the goals of DOTS is to avoid manual configuration.

-Tiru

From: Jon Shallow <supjps-ietf@jpshallow.com>
Sent: Wednesday, September 5, 2018 5:35 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] Data Channel - Deletion of Aliases when manually configured on DOTS Server


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi Tiru,

Unfortunately, manual / direct configuration is supported in the architecture draft, so cannot just be avoided.

SIG-007
….
      DOTS agents MUST support mitigation scope aliases, allowing DOTS
      client and server to refer to collections of protected resources
      by an opaque identifier created through the data channel, direct
      configuration, or other means.

I agree with there being potential confusion when things are configured in multiple places, and troubleshooting  can get complicated.

I think we need a way of reflecting back to the DOTS client what is happening.

Regards

Jon

From: Dots [mailto: dots-bounces@ietf.org<mailto:dots-bounces@ietf.org>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 05 September 2018 11:38
To: Jon Shallow; dots@ietf.org<mailto:dots@ietf.org>
Subject: Re: [Dots] Data Channel - Deletion of Aliases when manually configured on DOTS Server

Manual configuration creates conflicts with the DOTS protocols (just like the conflicts network devices would face if configured using both SDN and manual configuration) and I guess should be avoided.

-Tiru

From: Dots <dots-bounces@ietf.org<mailto:dots-bounces@ietf.org>> On Behalf Of Jon Shallow
Sent: Wednesday, September 5, 2018 3:57 PM
To: dots@ietf.org<mailto:dots@ietf.org>
Subject: [Dots] Data Channel - Deletion of Aliases when manually configured on DOTS Server


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi There,

When there is a manual configuration on the DOTS server of an alias by an operator, not created by the DOTS client, what should happen if the DOTS client tries to delete the alias?

The DOTS client will see the alias in a GET request for all aliases (as it is entitled to use it)

Returning a 404 (Not Found) could be confusing

Returning a 204 (No Content) is not right as it has not been deleted per se.

Should the alias in the GET response be marked as permanent (or some equivalent)?

The same is true for ACLs

Regards

Jon

v2.23.0 | Report a Bug | By Email