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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Thu, 06 September 2018 08:52 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 B7084130DEA for <dots@ietfa.amsl.com>; Thu, 6 Sep 2018 01:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level:
X-Spam-Status: No, score=-4.309 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, URIBL_BLOCKED=0.001] 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 DunHTcn3gf-D for <dots@ietfa.amsl.com>; Thu, 6 Sep 2018 01:52:22 -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 9F29C130DD5 for <dots@ietf.org>; Thu, 6 Sep 2018 01:52: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=1536223946; 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: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: authentication-results: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=sTJUZVlLUOOPrIM9kVfeQ5tJPE3o3E1z6sH3uy vw5nA=; b=W3R5XQh9zxjpVRnu8e7v0NME7dLLBlfAWvpH75Y2 DRYPZlJoZ2U0aXo1JUkmou9SlIb4kvh30B5ZOEVtt8Qm0rxl+f vkGPJBRq/kXlM03BpQrTPmih/mTIcUPwQsiREaL7h15O7bdki2 VBavGKW/vpjx+Njh2W9+ua2qyQYBACA=
Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5241_3125_ec2b483b_68e5_41de_a782_316d65229fb2; Thu, 06 Sep 2018 03:52:25 -0500
Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 6 Sep 2018 02:51:49 -0600
Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 6 Sep 2018 02:51:48 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 6 Sep 2018 02:51:48 -0600
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 6 Sep 2018 02:51:44 -0600
Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1650.namprd16.prod.outlook.com (10.172.27.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.15; Thu, 6 Sep 2018 08:51:46 +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.019; Thu, 6 Sep 2018 08:51:46 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Jon Shallow <supjps-ietf@jpshallow.com>, "dots@ietf.org" <dots@ietf.org>, "Mortensen, Andrew" <amortensen@arbor.net>
Thread-Topic: [Dots] Data Channel - Deletion of Aliases when manually configured on DOTS Server
Thread-Index: AdRFAu54VN0AjTquSDWy2o8cWBv6OwAAL20gAANB7AAAAP15oAABloCAAAC59CAAAKHXgAAnfdIg
Date: Thu, 06 Sep 2018 08:51:46 +0000
Message-ID: <BN6PR16MB14259DF6E193C6006BF79CA3EA010@BN6PR16MB1425.namprd16.prod.outlook.com>
References: <006401d44502$eedc4090$cc94c1b0$@jpshallow.com> <BN6PR16MB14255336A8BCE46C9BBAD404EA020@BN6PR16MB1425.namprd16.prod.outlook.com> <009c01d44510$b4f81ee0$1ee85ca0$@jpshallow.com> <BN6PR16MB1425DA13BFE5767CAA90D578EA020@BN6PR16MB1425.namprd16.prod.outlook.com> <00cb01d4451b$04807cf0$0d8176d0$@jpshallow.com> <BN6PR16MB1425C312B7D513A40F886025EA020@BN6PR16MB1425.namprd16.prod.outlook.com> <010001d44520$746827c0$5d387740$@jpshallow.com>
In-Reply-To: <010001d44520$746827c0$5d387740$@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
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR16MB1650; 6:osqGjCIy6tZb9xH4if3hKbmRF3kN0WEney1nraIyarZELLqbE8Rb3kYf29dwkIMzreekgKoUx98RuyRHcLAI4kupkruAkM4iBYg4HVP2+F/G/GFzOM4EQF4nXeeDY84niCO7X9F2gZIvY5ebsH2dBlRy0zb5TA+rVau1AKkLv6TR/5540Cp1GglkpD5BqRV/Serw/sZdZ97M+omJi7ZYdpex2UgWCBMSXHl1cYrsQ8nWxcPF5wxCKrcFb3NZ9upY1Ysm03Dzystwo8OyPWErf441+h2ji72cJbeDhKRqrl7GTMgt+WZ45f6x4dV4EgkHi/HuSCkAZRW/4JwI7sxSppVtL6RoOTFuSvM4zTbUM4d2thSu6DtuhjOSgfFAe0CVDAdMxqkWuxYxTtQCxDc8PR/ylQFfuutNThIveyUDJIPgV3GqbUKuOWDWkrs3CfnYAQxDli77yY/tgTsHoWzcPw==; 5:LSWCXjhADHh7FazQtvGhygNb4W2YbErzGsd8YwC2wrzw7/SQ3aJZ7/b/djkm8pvz0A3Jr/tKk8SVECvahd0el+9OsAtFX97TxLgGcTLW0cwLJSrDLgN5lVPqSAFer/2LZ2fTdxISV8q8STkRN3hp1rqF2R2QQUbfxwbzx5HU3sw=; 7:5KbnJy8hCJm9q9wa4T9kvn1ECjOJBstnYPPLeJ/KP4S4kLzohuYFssVfvG8CKtIQv6l9GxtAY/zv1TcP8esAWzbNUW/KuMu6A47Png6XIXptW6+nYwwaPVp8j34CXHUp24HkoK4rZPxymAHMoi0zw/PZCH1WxYrSPUEwfin5AToR8SWP78OePy2udqI1p5Ql1baspfVozdX81bkUr+xI+0+D1+EKmSwhEYU9ZpRwvtqjDZVYfFOCLFKHKlOV0cqe
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 203a5fa0-3ebf-4235-04b5-08d613d5fa12
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1650;
x-ms-traffictypediagnostic: BN6PR16MB1650:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-microsoft-antispam-prvs: <BN6PR16MB1650FD0A66DC72E1DD1F52A6EA010@BN6PR16MB1650.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)(5005006)(8121501046)(3231344)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699049)(76991033); SRVR:BN6PR16MB1650; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1650;
x-forefront-prvs: 0787459938
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(136003)(376002)(346002)(32952001)(199004)(189003)(25786009)(19609705001)(93886005)(8676002)(81166006)(5660300001)(6246003)(66066001)(97736004)(3846002)(33656002)(6116002)(5250100002)(80792005)(14454004)(99286004)(76176011)(106356001)(790700001)(2900100001)(7696005)(74316002)(81156014)(2501003)(53936002)(446003)(11346002)(476003)(486006)(102836004)(72206003)(6506007)(478600001)(105586002)(26005)(186003)(86362001)(9326002)(8936002)(53546011)(229853002)(236005)(68736007)(55016002)(7736002)(5024004)(316002)(9686003)(54896002)(256004)(6306002)(2906002)(110136005)(6436002)(14444005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1650; 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: CHBOgyabeeycouXRVzw5YMiBiQ3/8rKkHTWIN6o0oC6y499zrMSqPlGKRFvNkWCoYPHrtjUjjHM71YhybTIZB7DkOc7DQlz22m79ps4pER/z5pmkV1dN/aJztqFNiw6r+nUxBoyV94rUgMN8MSmf0pdwDCdGHL2wvA1+qdZ6GiJSLL2flpHGInYI6NDgylsoGafJVczNvviFLd3oeG9p+Uwp5TPEG6v/UazRU6m2o0ThFJ8gnp545h2PID+W6kKMrnWAc1oHmf6rbiumte7PilyP2Tq9OZ9YXcPC8EULGrDcj5v9M2FqsyFZcoB3rgfP5/5cRg6idPH0ok3tBL0Zu9fMOcSZ9GSbm9TtN9kkJZ8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR16MB14259DF6E193C6006BF79CA3EA010BN6PR16MB1425namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 203a5fa0-3ebf-4235-04b5-08d613d5fa12
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2018 08:51:46.3169 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1650
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 <6860> : streams <1797647> : uri <2704133>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Q4i-cz2Foqu2i2X5K5RoyXrOAXo>
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: Thu, 06 Sep 2018 08:52:25 -0000

Hi Jon,

Direct configuration is possible when the DOTS client and server are in the same domain.

-Tiru

From: Jon Shallow <supjps-ietf@jpshallow.com>
Sent: Wednesday, September 5, 2018 7:28 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org; Mortensen, Andrew <amortensen@arbor.net>
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,

I guess I missed / don’t currently recall that WG discussion (but can see the merit in having a standard set of aliases available to the DOTS clients which are just configured on the DOTS server).  I am trying to think of how the DOTS client configures directly without the data channel, but am failing to come up with how to do that without, say,  the operator doing it directly on the DOTS server.  “or other means” gets even more confusing.

I agree that directly/data channel methods are potentially mutually exclusive, but then the DOTS client/DOTS server need to negotiate which exclusive method to use…

It may just be simpler to drop a small amount of text.

Regards

Jon

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

We meant DOTS client either uses data channel or direct configuration to create the aliases but not use both. It was discussed in the WG sometime back that DOTS client may or may not use DOTS data channel to create aliases and hence direct configuration got added but both modes are mutually exclusive.

-Tiru

From: Jon Shallow <supjps-ietf@jpshallow.com<mailto:supjps-ietf@jpshallow.com>>
Sent: Wednesday, September 5, 2018 6:49 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com<mailto:TirumaleswarReddy_Konda@McAfee.com>>; dots@ietf.org<mailto:dots@ietf.org>; Mortensen, Andrew <amortensen@arbor.net<mailto:amortensen@arbor.net>>
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,

I meant the draft requirements document (and for some reason looking at an old draft (not the -15 version )) – I guess that this text needs to get updated then to remove the possibility of manual / direct configurations.

SIG-008
….
Old
      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.

SIG-008
….
New:
      DOTS agents MUST support mitigation scope aliases, allowing DOTS
      clients and servers to refer to collections of protected resources
      by an opaque identifier created through the data channel.

Regards

Jon

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

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<mailto:supjps-ietf@jpshallow.com>>
Sent: Wednesday, September 5, 2018 5:35 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com<mailto:TirumaleswarReddy_Konda@McAfee.com>>; dots@ietf.org<mailto: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