IETF Logo Mail Archive

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

"Jon Shallow" <supjps-ietf@jpshallow.com> Wed, 05 September 2018 12:05 UTC

Return-Path: <supjps-ietf@jpshallow.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 604F9130E1F for <dots@ietfa.amsl.com>; Wed, 5 Sep 2018 05:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 rc5TVA9I2I66 for <dots@ietfa.amsl.com>; Wed, 5 Sep 2018 05:05:17 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 BCE9D130DFE for <dots@ietf.org>; Wed, 5 Sep 2018 05:05:17 -0700 (PDT)
Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from <jon.shallow@jpshallow.com>) id 1fxWYb-0000kL-VB; Wed, 05 Sep 2018 13:05:14 +0100
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: "'Konda, Tirumaleswar Reddy'" <TirumaleswarReddy_Konda@mcafee.com>, dots@ietf.org
References: <006401d44502$eedc4090$cc94c1b0$@jpshallow.com> <BN6PR16MB14255336A8BCE46C9BBAD404EA020@BN6PR16MB1425.namprd16.prod.outlook.com>
In-Reply-To: <BN6PR16MB14255336A8BCE46C9BBAD404EA020@BN6PR16MB1425.namprd16.prod.outlook.com>
Date: Wed, 05 Sep 2018 13:05:14 +0100
Message-ID: <009c01d44510$b4f81ee0$1ee85ca0$@jpshallow.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_009D_01D44519.16BD7140"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQE6SuqbgaHwuLnsNF195LRVeluWLgIS/c38pgTxrBA=
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/R69dfu7F9HnNZnZONJqDdgRIiE8>
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 12:05:20 -0000

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] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 05 September 2018 11:38
To: Jon Shallow; 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> On Behalf Of Jon Shallow
Sent: Wednesday, September 5, 2018 3:57 PM
To: 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