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

"Jon Shallow" <supjps-ietf@jpshallow.com> Thu, 06 September 2018 12:13 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 CC71B128CF3 for <dots@ietfa.amsl.com>; Thu, 6 Sep 2018 05:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 X5Z6DkMzkxRJ for <dots@ietfa.amsl.com>; Thu, 6 Sep 2018 05:13:18 -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 BE37312872C for <dots@ietf.org>; Thu, 6 Sep 2018 05:13: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 1fxt9t-0001i4-OD; Thu, 06 Sep 2018 13:13:15 +0100
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: "'Konda, Tirumaleswar Reddy'" <TirumaleswarReddy_Konda@mcafee.com>, dots@ietf.org, "Mortensen, Andrew" <amortensen@arbor.net>
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> <BN6PR16MB14259DF6E193C6006BF79CA3EA010@BN6PR16MB1425.namprd16.prod.outlook.com> <01be01d445c1$5d475e70$17d61b50$@jpshallow.com> <BN6PR16MB1425D8975C6FE57D1F93B19FEA010@BN6PR16MB1425.namprd16.prod.outlook.com>
In-Reply-To: <BN6PR16MB1425D8975C6FE57D1F93B19FEA010@BN6PR16MB1425.namprd16.prod.outlook.com>
Date: Thu, 06 Sep 2018 13:13:12 +0100
Message-ID: <001501d445da$fda9fcb0$f8fdf610$@jpshallow.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01D445E3.5F719900"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQE6SuqbgaHwuLnsNF195LRVeluWLgIS/c38AgtXmIIBySqHdQHnu4vHAnga8vUBr/+2ugHqmXMMATT3PMgBb6OCjKWS6JrQ
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/wAqcpjoGA2YnOYxSy_qoW3_5s8Y>
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 12:13:21 -0000

Hi Tiru,

 

Yes, only one or the other method (data channel v direct) should be used.

 

However, both the DOTS client and DOTS server need to be configured that this is the way to do it, but then if the DOTS server is actually is a DOTS gateway, then the upstream (ultimate) DOTS server (which could be in the same domain or not) needs to be configured in the same way as the initial DOTS client.  A recipe for misconfiguration and confusion.

 

The DOTS client needs to be told by the (ultimate) DOTS server which method is being used / supported, and this can be in the response code (or embedded in the response message) when the client (due to misconfiguration) does an unexpected DELETE or PUT.  It could be in the GET response where the alias is marked as ‘permanent’.  

 

Regards

 

Jon

 

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

 

Hi Jon,

 

I thought we agreed direct configuration and DOTS data channel are mutually exclusive. If a client uses DOTS data channel, it must not perform direct configuration and vice-versa. 

 

Cheers,

-Tiru

 

From: Dots <dots-bounces@ietf.org> On Behalf Of Jon Shallow
Sent: Thursday, September 6, 2018 2:39 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,

 

If that is the case (and I do not disagree with what you have said – I think it is the right thing to do to support direct configuration), then we go back to the original question (with manual replaced by direct)

 

How does the DOTS client know that it is trying to delete an alias that was directly configured?

 

This then leads to another question.  What happens if the DOTS client tries to PUT update a direct configuration?

 

Two use cases for consideration.

 

First, the direct configuration specifies the CUID.

 

Second, the direct configuration is CUID agnostic and applies to all DOTS clients.

[The PUT could create an alias+CUID which takes precedence over direct-alias]

 

Regards

 

Jon

 

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

 

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] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 05 September 2018 14:44
To: Jon Shallow; 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> 
Sent: Wednesday, September 5, 2018 6:49 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 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] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 05 September 2018 14:01
To: Jon Shallow; 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> 
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] 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