Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-channel-28: (with DISCUSS and COMMENT)

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Wed, 03 July 2019 08: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 59779120733; Wed, 3 Jul 2019 01:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 MUCuRiC2_uxY; Wed, 3 Jul 2019 01:01:37 -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 B87E712073A; Wed, 3 Jul 2019 01:01:36 -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=1562140283; h=From: To:CC: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-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding: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-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: 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=DrI2GInv8BY0+0qipb675fHkFoH2exjt966Ur7 PcvnM=; b=RGl4OW2WzTFtCtAej3P6Q1DTRiGexIaSOKqNijBz vPzPHH8eDpDTO7QFmS9Bjoq2Fc7mm5aVau/LwbfLKK5EjwogZD +FbpOQ0yRBA9hYkk7wTvc9ONeFTlSKD1NykERrQYuao2nOMcVe qoE0+tQUxExt600SiCf7xUSGjIjQe3U=
Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3a74_01a8_f1d232a2_9dee_4476_a6d4_d3d8dc6d808b; Wed, 03 Jul 2019 01:51:22 -0600
Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 3 Jul 2019 02:00:58 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 3 Jul 2019 02:00:58 -0600
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 3 Jul 2019 02:00:57 -0600
Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB2262.namprd16.prod.outlook.com (52.132.142.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Wed, 3 Jul 2019 08:00:57 +0000
Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::89e6:d84d:9681:1065]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::89e6:d84d:9681:1065%5]) with mapi id 15.20.2032.019; Wed, 3 Jul 2019 08:00:57 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
CC: Benjamin Kaduk <kaduk@mit.edu>, Roman Danyliw <rdd@cert.org>, "dots@ietf.org" <dots@ietf.org>, The IESG <iesg@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "draft-ietf-dots-data-channel@ietf.org" <draft-ietf-dots-data-channel@ietf.org>
Thread-Topic: =?utf-8?B?W0RvdHNdICBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1p?= =?utf-8?B?ZXRmLWRvdHMtZGF0YS1jaGFubmVsLTI4OiAod2l0aCBESVNDVVNTIGFuZCBD?= =?utf-8?Q?OMMENT)?=
Thread-Index: AQHVAN3ugjmuTslNjEWiBUcliI6afaa2ROeAgAAN3QCAAQGxAIAAaHOAgAABS2CAAButAIABDrLg
Date: Wed, 3 Jul 2019 08:00:57 +0000
Message-ID: <DM5PR16MB170519F8C328B05B9ED61EECEAFB0@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <155679628494.24951.9145538661531263463.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA68C8B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190701154032.GB13810@kduck.mit.edu> <A4BD2109-EC58-4FED-A8B0-2EE5AC47A69C@kuehlewind.net> <DM5PR16MB1705BED0F42996593B0C0A70EAF80@DM5PR16MB1705.namprd16.prod.outlook.com> <24FFE7CE-B91A-4CF4-BB85-D6108ACE0043@kuehlewind.net> <DM5PR16MB170529399AC19B88B321A35DEAF80@DM5PR16MB1705.namprd16.prod.outlook.com> <642531B0-3E3A-4A5C-BD20-C74AA3698936@kuehlewind.net>
In-Reply-To: <642531B0-3E3A-4A5C-BD20-C74AA3698936@kuehlewind.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.3.0.8
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [49.37.206.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 70e70aaf-844b-44f7-4b0f-08d6ff8c94c3
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB2262;
x-ms-traffictypediagnostic: DM5PR16MB2262:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <DM5PR16MB2262C2337C375A19C5AF25E2EAFB0@DM5PR16MB2262.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00872B689F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(39860400002)(396003)(366004)(376002)(32952001)(13464003)(189003)(199004)(256004)(25786009)(5024004)(14444005)(53936002)(9686003)(55016002)(66066001)(66574012)(6306002)(14454004)(6116002)(6436002)(3846002)(4326008)(86362001)(6246003)(6916009)(2906002)(102836004)(6506007)(966005)(68736007)(486006)(316002)(66946007)(66446008)(186003)(64756008)(66556008)(66476007)(73956011)(26005)(76116006)(53546011)(72206003)(478600001)(54906003)(76176011)(80792005)(224303003)(7696005)(74316002)(229853002)(71190400001)(305945005)(71200400001)(7736002)(99286004)(476003)(5660300002)(446003)(8936002)(81156014)(81166006)(11346002)(52536014)(33656002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2262; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: aDx/V5DaqzPT8XUEPFU8NWnw4W9ei5G8ARAMhBjNFIHxXsAml0Y6bqMOlqGpNn745jt+FcxqIIO5Vmym4Sy40doaI70LEuqo0tZVYBy+hXRICyEzHI6liAUnQuKqdXnXV1y11PhFXt4/2qdd0YqJMswrwrz5QLwr/BwDr8oFtk1BiVDyZ1cxQT4YTMD/LE1vCSVuBhAozpJMx4mzk4FRGtaiqKQ2+duQvTEnX9M81i7sGhOaKrY0vbvPyIgfNH1dhbisoldXuBIGTU7hd+bVmNgjptm01/EQk+7WtYuP9j+YA6L8yCZkjBE2CHtTsQufzCiXJqaogplK0MSgoCnV/fY5R/oz4XTvPSUcQFp1iceeBKNrPlIUPhi3BS6VNggZ4YhNnJcYSziN3x4izrV7bL0Bq6tiqD4agtuaQrSWrow=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 70e70aaf-844b-44f7-4b0f-08d6ff8c94c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 08:00:57.4593 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2262
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.8
X-NAI-Spam-Version: 2.3.0.9418 : core <6581> : inlines <7113> : streams <1826257> : uri <2863203>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/BMbckURsmeMKSy8jPmY9nF5ZMLw>
Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-data-channel-28=3A_=28with_DISCUSS_and_COMMENT=29?=
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, 03 Jul 2019 08:01:39 -0000

Hi Mirja,

Please see inline 

> -----Original Message-----
> From: Mirja Kuehlewind <ietf@kuehlewind.net>;
> Sent: Tuesday, July 2, 2019 9:20 PM
> To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
> Cc: Benjamin Kaduk <kaduk@mit.edu>;; Roman Danyliw <rdd@cert.org>;;
> dots@ietf.org; The IESG <iesg@ietf.org>;; dots-chairs@ietf.org;
> mohamed.boucadair@orange.com; draft-ietf-dots-data-channel@ietf.org
> Subject: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-
> channel-28: (with DISCUSS and COMMENT)
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Hi Tiru,
> 
> Below...
> 
> > On 2. Jul 2019, at 16:22, Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>; wrote:
> >
> >> -----Original Message-----
> >> From: Mirja Kuehlewind <ietf@kuehlewind.net>;
> >> Sent: Tuesday, July 2, 2019 7:36 PM
> >> To: Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>;
> >> Cc: Benjamin Kaduk <kaduk@mit.edu>;; Roman Danyliw <rdd@cert.org>;;
> >> dots@ietf.org; The IESG <iesg@ietf.org>;; dots-chairs@ietf.org;
> >> mohamed.boucadair@orange.com; draft-ietf-dots-data-channel@ietf.org
> >> Subject: Re: [Dots] Mirja Kühlewind's Discuss on
> >> draft-ietf-dots-data-
> >> channel-28: (with DISCUSS and COMMENT)
> >>
> >>
> >>
> >> Hi Tiru,
> >>
> >> Please see below.
> >>
> >>> On 2. Jul 2019, at 09:55, Konda, Tirumaleswar Reddy
> >> <TirumaleswarReddy_Konda@McAfee.com>; wrote:
> >>>
> >>>>>>> I would also quickly like to discuss the use of keep-alives as
> >>>>>>> described in Section 3.1: "While the communication to the DOTS
> >>>>>>> server is  quiescent, the DOTS client MAY probe the server to
> >>>>>>> ensure it has  maintained cryptographic state.  Such probes can
> >>>>>>> also keep alive  firewall and/or NAT bindings.  A TLS heartbeat
> >>>>>>> [RFC6520] verifies  that the DOTS server still has TLS state by
> >>>>>>> returning
> >> a TLS message."
> >>>>>>> I understood that multiple requests can and should be send in
> >>>>>>> the same connection, however, I would expect that those requests
> >>>>>>> are send basically right after each other, such as a look-up and
> >>>>>>> then change of the config. I don't see a need to keep up the
> >>>>>>> connection for a
> >>>> long time otherwise.
> >>>>>>> Especially any action performed are (other than in the signal
> >>>>>>> channel case) not time critical. Therefore I would rather
> >>>>>>> recommend to close and reopen connections and not recommend
> to
> >> use
> >>>>>>> keep-alives at all.
> >>>>>>
> >>>>>> [Med] The activity of the DOTS client may be used to track/detect
> >>>>>> stale
> >>>> entries:
> >>>>>>
> >>>>>> Also, DOTS servers
> >>>>>> may track the inactivity timeout of DOTS clients to detect stale
> >>>>>> entries.
> >>>>>>
> >>>> My understanding is that this is orthogonal. You can also see that
> >>>> a client is inactive when it didn’t open a new connection for a certain
> time…?
> >>>
> >>> The drop-list rules could be frequently updated by the DOTS client
> >>> based on the tests used by the DOTS client domain (e.g.
> >>> cryptographic
> >>> challenge) to detect whether the IP address is for legitimate use or
> >>> not, or based on threat intelligence feeds from security vendors
> >>> providing the botnet/malicious IP addresses feed.  Further,
> >>> persistent DOTS data channel is required to handle updates to target
> >>> resources (e.g. CDN hosting a domain, and it needs DDoS protection)
> >>> and target IP/prefix may also change frequently (mobile branch
> >>> office, prefix re-numbering etc.)
> >>
> >> This still doesn’t sounds like it is desirable to keep the TCP connection
> open.
> >> Also if you can bear the time to reconnect (1-2 RTT for the
> >> handshake) that is usually the better and easier options. I don’t
> >> think the information we talk about here are that time-critical, is
> >> it? When you say frequent what time frame do you mean, Hours, minutes,
> seconds, milliseconds?
> >
> > The frequency of updates to drop-list rules can be few milliseconds.  For
> example, CAPTCHA and cryptographic puzzles can be used by DOTS client
> domain to determine whether the IP address is used for legitimate purpose
> or not, and can configure the drop-list rules.
> > Further, the specification does not mandate the connection to be
> persistent, but when needed, the probe mechanism applies.
> 
> Then it really seems to me that the document would need to provide further
> guidance when a persistent connection is useful or when it is recommend to
> close the connection (and reopen if needed).

Sure, will add the following text:

   A DOTS client can either maintain a persistent connection or periodic
   connections with its DOTS server(s).  If the DOTS client needs to
   frequently update the drop-list or accept-list filtering rules or
   aliases, it maintains a persistent connection with the DOTS server.
   For example, CAPTCHA and cryptographic puzzles can be used by the
   mitigation service in the DOTS client domain to determine whether the
   IP address is used for legitimate purpose or not, and the DOTS client
   can frequently update the drop-list filtering rules.  A persistent
   connection is also useful if the DOTS client subscribes to event
   notifications (Section 6.3 of [RFC8040]).

- Tiru and Med
 
> 
> Mirja
> 
> 
> >
> > -Tiru
> >
> >>
> >> Mirja
> >>
> >>
> >>>
> >>> Further, we are not mandating the connection to be persistent, but
> >>> when
> >> needed, the probe mechanism applies. Please note
> >> https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-
> >> 13 discusses persistent-connection and it’s a client preference on
> >> how the connection is maintained (persistent or periodic).
> >