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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Sat, 08 September 2018 11:53 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 5B54F130DD1 for <dots@ietfa.amsl.com>; Sat, 8 Sep 2018 04:53:02 -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 5OOF8qTRdaRe for <dots@ietfa.amsl.com>; Sat, 8 Sep 2018 04:52:57 -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 7BCA4130DDE for <dots@ietf.org>; Sat, 8 Sep 2018 04:52:57 -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=1536407588; 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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=L 7EvqEE+tAOYTBXvzbOJ74URL+66q+WyccGyqT0Rru 0=; b=VgOE9Omt+o+7kNZxUaY68/8C8RKq9L05d+rbgAHXUyLz xGcxPyReltsPPQCkinwKKaVpzzk8yjTHX8TnynFeDUPguhFPhf a5JolGgp1QG3miZ5isA12QgqMl7Wpk111iUnr0OrDkFGUy3aeC FtdBMAlP39Gq9bI4e2oXFg/2veY=
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 49cb_561f_02dea061_2e90_4c04_bbed_02d6f8e5c884; Sat, 08 Sep 2018 06:53:06 -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; Sat, 8 Sep 2018 05:52:54 -0600
Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 8 Sep 2018 05:52:52 -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.1347.2 via Frontend Transport; Sat, 8 Sep 2018 05:52:52 -0600
Received: from NAM05-DM3-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.1347.2; Sat, 8 Sep 2018 05:52:51 -0600
Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1668.namprd16.prod.outlook.com (10.172.27.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.16; Sat, 8 Sep 2018 11:52:50 +0000
Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::517:e3a:5fb2:8a75]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::517:e3a:5fb2:8a75%5]) with mapi id 15.20.1122.017; Sat, 8 Sep 2018 11:52:50 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Jon Shallow <supjps-ietf@jpshallow.com>, "Mortensen, Andrew" <amortensen@arbor.net>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] Data Channel - Deletion of Aliases when manually configured on DOTS Server
Thread-Index: AdRFAu54VN0AjTquSDWy2o8cWBv6OwAAL20gAANB7AAAAP15oAABloCAAAC59CAAAKHXgAAnfdIgAAC5igAAAo9vUAAD20UAAAKPAPAAAsR1AAAaQRPwAAwLTAAAAtkk8AAD690AADFhO/A=
Date: Sat, 8 Sep 2018 11:52:49 +0000
Message-ID: <BN6PR16MB1425543EE269728371965EB7EA070@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> <BN6PR16MB14259DF6E193C6006BF79CA3EA010@BN6PR16MB1425.namprd16.prod.outlook.com> <01be01d445c1$5d475e70$17d61b50$@jpshallow.com> <BN6PR16MB1425D8975C6FE57D1F93B19FEA010@BN6PR16MB1425.namprd16.prod.outlook.com> <001501d445da$fda9fcb0$f8fdf610$@jpshallow.com> <BN6PR16MB1425DA462F8E058A6ABFE6DDEA010@BN6PR16MB1425.namprd16.prod.outlook.com> <00ac01d445f0$4ba1ceb0$e2e56c10$@jpshallow.com> <BN6PR16MB1425BEC03BBD351075E99DFEEA000@BN6PR16MB1425.namprd16.prod.outlook.com> <016701d44689$7ac2aef0$70480cd0$@jpshallow.com> <BN6PR16MB1425BCA5DBC5AF218F5E395AEA000@BN6PR16MB 1425.namprd16.prod.outlook.com> <022001d446a4$8e9901c0$abcb0540$@jpshallow.com>
In-Reply-To: <022001d446a4$8e9901c0$abcb0540$@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: [185.221.69.47]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR16MB1668; 6:xhEMCzk3lQ7HuRT5fEYtbsyXZ33Devd0xQ2dICM7P2G4B8Pg1GmwgoMCfnlhyzTELg1qz95LkD7+oUVEiwbOtzSfjFCrl9hmKTth46dGlF20wgU0QcSnGWaHPDSlZYwJKx261fx37JzP1zX6kyYIr0uSYfqEzZH5apRV4noLVjQqY7iwCB8FNrd3FMJAd0S5qzUGJJIEWi5kc/1tBc6lN9D49C11qTNDPGETdSsRJcMsMfL/GTubt8dOtM3mCTp6WCrADkzE+mB1EprowYcru5gdqobHKByfciITGcFUCKZw74nt+PvAxi0eppETwtFK2ra5WxDRInzu4MSGWDePaTmMAI+KjI7Kc+djoy9KXQ9E/4mVjlgPDdmGO/n9idtOBb06aBjWpdCVxtBAizwV17GLIG39gpv9knlb1Lx8/k2R/uzEUko7Us8rIz17tklqnI2FaxTteXuPjLm7G9sG6A==; 5:cxl5HHDR/qxXgXvKn2l2z7cgSuoH6luFQt173aE2ArTnM1V/FC4Ao+q0G2YwGXQcS9Cq85D6AP02pLqKYW6+0CagyNfA5ROZqOalgPMQZPMmMMEtbH/J+8PJ8G2BcpVKe9swohqFuswwkPWmPZkXliA1Vq3Zy9yi86B884xz2VU=; 7:HFD7LgV98WpySDylrPoLjUJfGTNBxPNevrQq6c+Upmreh6Z2iZJ67nDun/A7tI9ij8zscyU19D07NeF5TZ8TcPHyDa3sgpgnMyVWUvbCpcG6iQLQa/jJ/An9JWX2SljcsMOMKO3vBRFCz3d/AVnW5HgR8+RcrKacEdhzCrbFyOicHLbDe6JifEe8o57XBswbsEY3PXSHprxxpc7rRDaZNrIVcAabonURAMZA8gu3ZvkS6p6o9x1JCz5w4aXZvEpT
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 1525bc5d-7110-4f61-7bcf-08d615819a23
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1668;
x-ms-traffictypediagnostic: BN6PR16MB1668:
x-microsoft-antispam-prvs: <BN6PR16MB1668326FC058B94DCDF87055EA070@BN6PR16MB1668.namprd16.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(103651359005742)(269456686620040)(21748063052155)(21532816269658)(123452027830198);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(10201501046)(149027)(150027)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(201708071742011)(7699050); SRVR:BN6PR16MB1668; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1668;
x-forefront-prvs: 07891BF289
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(376002)(366004)(346002)(39860400002)(199004)(189003)(45914002)(32952001)(3846002)(72206003)(478600001)(6436002)(53936002)(446003)(966005)(93886005)(236005)(53946003)(606006)(6116002)(54896002)(6306002)(55016002)(9686003)(790700001)(186003)(110136005)(8676002)(316002)(2501003)(229853002)(74316002)(7736002)(102836004)(53546011)(86362001)(97736004)(6506007)(11346002)(80792005)(26005)(5250100002)(25786009)(106356001)(8936002)(66066001)(7696005)(76176011)(476003)(99286004)(105586002)(81166006)(81156014)(68736007)(2906002)(6246003)(14454004)(2900100001)(486006)(33656002)(256004)(19609705001)(5660300001)(14444005)(5024004)(85282002)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1668; 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: 3XH+inbYKykZtySLBqVXY+xGXSWEUxo6T7DcxOnKIYplQiYhD6CXBpNluSQeR9QlnnAWzPKSmjK8mG23cgRd13BHTqJ8lBi9kEmDn+hpW95hqIT9T8dDS0K0lY8Cl/sggErh5dO5wzyk0HdzOHnS9LgAbM2HOub0tB55usjnU2acnF3ZeKhha790LdnXnXS8U3zR3vHMTMJzA8rcHueN9/YvVfYAhXYr+olqFLsrrw7XKnNLy1OQdq8BtoUJRZmh/5VLpEvt7O4blxFFcPC+N8jMDd26D6myTeDjZ8Ap0PqREIop5Esnd5TNhdudrN929kRuFN0tV/aEr2omitbl9/UmGnmahczKANeOipY7CdI=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1425543EE269728371965EB7EA070BN6PR16MB1425namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1525bc5d-7110-4f61-7bcf-08d615819a23
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2018 11:52:49.9547 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1668
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0
X-NAI-Spam-Version: 2.3.0.9418 : core <6369> : inlines <6865> : streams <1797849> : uri <2705811>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/lbIyCXafR-W8t5Rjzh9ZFPBgQHc>
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: Sat, 08 Sep 2018 11:53:02 -0000

Thanks, Jon. Your proposed text looks good to me.

Cheers,
-Tiru

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

See inline Jon1>

Regards

Jon

From: Dots [mailto: dots-bounces@ietf.org<mailto:dots-bounces@ietf.org>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 September 2018 11:56
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

Hi Jon,

Please see inline [TR2]

From: Dots <dots-bounces@ietf.org<mailto:dots-bounces@ietf.org>> On Behalf Of Jon Shallow
Sent: Friday, September 7, 2018 2:32 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 believe that we are getting towards closure on this one.

[TR2] Yes.

See inline Jon>

Regards

Jon

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 September 2018 06:40
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

Hi Jon,

Please see inline

From: Jon Shallow <supjps-ietf@jpshallow.com<mailto:supjps-ietf@jpshallow.com>>
Sent: Thursday, September 6, 2018 8:16 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 guess I may be missing something here, but whatever is decided needs to go into either the data channel draft, or requirements draft for clarity on how to handle direct configuration or data channel configuration.

[TR] I guess it’s too late to modify the requirements draft, but we can update the data channel draft. We can add the following lines:

DOTS server MUST not enable both DOTS data channel and direct configuration to avoid race conditions, inconsistent configurations arising from simultaneous updates from multiple sources. DOTS agents SHOULD use DOTS data channel and only use direct configuration as a stop-gap mechanism to test the DOTS signal channel with aliases. In addition, direct configuration SHOULD only be used when all the DOTS agents are within the same domain. If the DOTS server has enabled direction configuration,
Jon> “direct configuration”, not “direction configuration”

[TR2] Thanks, will fix.

it can reject DOTS channel connection using hard ICMP error [RFC1122].  To interfere with the DOTS data channel, an attacker might send an ICMP error message towards the DOTS client.  The counter-measures discussed in [RFC5927] can be used to guard against ICMP attacks.
Jon> ICMP is a bad mechanism to use – it can be blocked by firewalls, not easy to access in an application on a TCP connection, difficult to pass through a DOTS gateway etc.

[TR2] TCP must act on the ICMP error messages (see  https://tools.ietf.org/html/rfc5461#section-2.2<https://www.ietf.org/rfc/rfc1122.txt>)t>), NAT/firewalls do permit inbound ICMP errors (you may want to look into the example given in https://tools.ietf.org/html/rfc5508#section-4.2). If all the DOTS agents are in the same domain, they would be typically behind NAT and firewall.
Jon1> TCP does – “Connection Refused” on the hard ICMP errors when doing connect(), but getting to the actual ICMP packet is more of a challenge.  RFCs say that the ICMP error must be passed back – a lot of people misconfigure this on firewalls etc. as they perceive this to be a bad thing, or do not properly understand how IP works.

If the server is not accepting connections, then a TCP RST is passed back – much simpler to handle.  So, for me, a better text could be
it can reject the DOTS channel connection by not listening on the data channel port, or by sending back a 503 status code.

[TR2] 503 status code looks more suitable and will be an authentic message, TCP RST is abrupt and does not provide any diagnostic information.
NEW:
If the DOTS server has enabled direct configuration, it can reject the DOTS data channel connection using hard ICMP error [RFC 1122] or reject the RESTCONF request using an error response containing a “503 Service Unavailable” status-line.
Jon1> In my real world experience of TCP, the most usual rejection of a TCP connection is the use of the RST flag bit when the server is not listening on that particular port.  ICMP response is usually triggered by (Linux) using iptables ‘–j REJECT’ (and I don’t think the hard errors can tell you anything more useful than a RST).  So, to be a bit more general
Jon1>NEW:
If the DOTS server has enabled direct configuration, it can reject the DOTS data channel connection using hard ICMP error [RFC 1122], a TCP packet with the RST control bit set[RFC 793] or reject the RESTCONF request using an error response containing a “503 Service Unavailable” status-line.

~jon1

-Tiru

If we shut down the use of the Data Channel as the DOTS server is only supporting direct configurations, then this will be for both the Alias and ACL definitions.

[TR] Yes, and direct configuration is not the recommended approach. It’s just a stop-gap mechanism to test DOTS signal channel without data channel.

This violates, for instance
   DATA-004  Black- and whitelist management: DOTS servers MUST provide
      methods for DOTS clients to manage black- and white-lists of
      traffic destined for resources belonging to a client.
and potentially (depending on what you understand ‘interface’ as meaning)
   DATA-003  Resource Configuration: To help meet the general and signal
      channel requirements in Section 2.1 and Section 2.2, DOTS server
      implementations MUST provide an interface to configure resource
      identifiers, as described in SIG-007.  DOTS server implementations
      MAY expose additional configurability

[By the way DATA-003 refers to SIG-007 – which should be SIG-008 – needs correcting]

[TR] Yes, will fix in the next revision.

Being selective on whether it is Alias or ACL before generating a TLS fatal alert is messy and not very clean.  Fatal alerts are usually used during session setup, I can’t immediately find a suitable fatal alert to use – and whatever it is would need to be defined in the data channel.

Also, propagating a TLS fatal Alert through a DOTS gateway could be interesting – especially as the downstream hop has to establish TLS to find out what to do before making the ongoing connection to the upstream DOTS agent.

[TR] If a server enables direct configuration as a stop gap, I don’t see a point running the server just to return errors, ICMP error should suffice.
Jon> Again, it would be a RST, not ICMP if the server was not running / listening on the port in question.

Again, an additional ro YANG field such as “permanent”: true, or perhaps “directly-configured”: true for the Alias and ACL would be sufficient here for the DOTS client to work out what is going on.  Is there any reason as to why this should not be done?

[TR] I don’t think it’s a good idea to enhance the YANG module to convey/modify direction configuration, I don’t see any such provision and discussion in NETFCONF and RESTCONF.
Jon> OK.  The TCP RST (or perhaps 503 response) works for me.
~Jon
-Tiru

Regards

Jon

From: Dots [mailto: dots-bounces@ietf.org<mailto:dots-bounces@ietf.org>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 06 September 2018 15:05
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

Hi Jon,

If the ultimate DOTS server supports only direct configuration, it should reject the DOTS data channel connection from the DOTS client, for example appropriate error response code (e.g. TLS fatal alert) can be returned.  The error returned by the ultimate DOTS server can be propagated by the DOTS gateway to the DOTS client. DOTS client will eventually have to rely on direct configuration.

-Tiru

From: Jon Shallow <supjps-ietf@jpshallow.com<mailto:supjps-ietf@jpshallow.com>>
Sent: Thursday, September 6, 2018 5:43 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,

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<mailto:dots-bounces@ietf.org>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 06 September 2018 11:26
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

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<mailto: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<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,

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<mailto:dots-bounces@ietf.org>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 06 September 2018 09:52
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

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<mailto:supjps-ietf@jpshallow.com>>
Sent: Wednesday, September 5, 2018 7:28 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 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