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> Tue, 02 July 2019 07:55 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 CAA4B1200B3; Tue, 2 Jul 2019 00:55:47 -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 KclOizzSWMIF; Tue, 2 Jul 2019 00:55:45 -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 B8F25120019; Tue, 2 Jul 2019 00:55:44 -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=1562053535; 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=VbxBWjvqUKX2KWNnwJOETQTYN1PWajboduFyfC 957iI=; b=Fl8Gc9KXB1xMRA5pHhYYajqgOLnzlQl47/5b08PT 5aowDLPNuJkxfAUXQC7UuKFPRgG9eK/NhN1w1qiiJ6KQBqtnJs G8axw0/S/yiMyvCPXBGynh3O45Iia8Kuuhf+Tj9mBKqRcYMC3a mKOypUndg5QWbq7IeXKfQ0oVFlzvHAA=
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 60b6_410e_19118b34_51ea_4211_b546_c7d07f86ca09; Tue, 02 Jul 2019 01:45:34 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 2 Jul 2019 01:55:18 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 2 Jul 2019 01:55:18 -0600
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 2 Jul 2019 01:55:17 -0600
Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1465.namprd16.prod.outlook.com (10.173.210.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.18; Tue, 2 Jul 2019 07:55:16 +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; Tue, 2 Jul 2019 07:55:16 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>, Benjamin Kaduk <kaduk@mit.edu>
CC: 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: AQHVAN3ugjmuTslNjEWiBUcliI6afaa2ROeAgAAN3QCAAQGxAA==
Date: Tue, 2 Jul 2019 07:55:15 +0000
Message-ID: <DM5PR16MB1705BED0F42996593B0C0A70EAF80@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>
In-Reply-To: <A4BD2109-EC58-4FED-A8B0-2EE5AC47A69C@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: 00cc8e36-07c8-454b-a93c-08d6fec29ec6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1465;
x-ms-traffictypediagnostic: DM5PR16MB1465:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <DM5PR16MB14655AA47760FC27CE984313EAF80@DM5PR16MB1465.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 008663486A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(376002)(396003)(136003)(346002)(32952001)(13464003)(199004)(189003)(6306002)(224303003)(7736002)(256004)(66066001)(305945005)(33656002)(66946007)(54906003)(14444005)(316002)(55016002)(66556008)(110136005)(76176011)(76116006)(2906002)(73956011)(74316002)(8936002)(6116002)(11346002)(25786009)(68736007)(66446008)(446003)(476003)(64756008)(4326008)(486006)(6436002)(71200400001)(71190400001)(66574012)(3846002)(7696005)(81156014)(81166006)(186003)(102836004)(26005)(14454004)(86362001)(229853002)(966005)(2171002)(72206003)(5660300002)(478600001)(6506007)(53936002)(99286004)(6246003)(80792005)(53546011)(9686003)(66476007)(52536014)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1465; H:DM5PR16MB1705.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-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: tU0rr+2Q40cUbYe8iE3TvjW7iwmE8OnQigu2R0EUY3D/i/DWgPoxACcjT091MSNIA+ERXOK+wtw/EOwCEgekVgrDWHw3HZ9KZ4iqvX6JIiSBoiuML3S8VNSGa8XJJPmG80yoq945rOzG7gpGb1902IRvJf3y83XlWx0k6Rq5FVaJNXuqjTD+Mg/OqmIRSyo9gPVGm/V9e7tlcE4N+fth15mwTTlcb7+RxCbiGcq99E+R205g2UWlbwbK0tBNqZDoAGZsnoj5dgt/D7NgBS0q3eIvVfhnnfhWZybmfblBhsUIW7nMB5YFBG3Y93/lQVhPaTLJ/bA68IGHLZ1nvSalFLfeR5uTRWCjX+ZDbmyXycbRNp4YnwjsfY7j4B+bZose26+oXhy6k/kNdMkj42ubQ4ssHp9uIbnyFhkAhE2URFY=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 00cc8e36-07c8-454b-a93c-08d6fec29ec6
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2019 07:55:15.9122 (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: DM5PR16MB1465
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.2
X-NAI-Spam-Version: 2.3.0.9418 : core <6580> : inlines <7113> : streams <1826164> : uri <2862814>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/0NOZOdolWkZBciB-p4Vs80O2D-E>
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: Tue, 02 Jul 2019 07:55:48 -0000

Hi Mirja,

Please see inline

> -----Original Message-----
> From: Dots <dots-bounces@ietf.org>; On Behalf Of Mirja Kuehlewind
> Sent: Monday, July 1, 2019 10:00 PM
> To: Benjamin Kaduk <kaduk@mit.edu>;
> Cc: 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 Ben, hi Med,
> 
> Please see below.
> 
> > On 1. Jul 2019, at 17:40, Benjamin Kaduk <kaduk@mit.edu>; wrote:
> >
> > Hi Mirja,
> >
> > Can you please let us know whether these replies address your concerns?
> >
> > Thanks,
> >
> > Ben
> >
> > On Thu, May 02, 2019 at 11:54:50AM +0000,
> mohamed.boucadair@orange.com wrote:
> >> Re-,
> >>
> >> Please see inline.
> >>
> >> Cheers,
> >> Med
> >>
> >>> -----Message d'origine-----
> >>> De : Mirja Kühlewind via Datatracker [mailto:noreply@ietf.org]
> >>> Envoyé : jeudi 2 mai 2019 13:25 À : The IESG Cc :
> >>> draft-ietf-dots-data-channel@ietf.org; Roman Danyliw; dots-
> >>> chairs@ietf.org; rdd@cert.org; dots@ietf.org Objet : Mirja
> >>> Kühlewind's Discuss on draft-ietf-dots-data-channel-28: (with
> >>> DISCUSS and COMMENT)
> >>>
> >>> Mirja Kühlewind has entered the following ballot position for
> >>> draft-ietf-dots-data-channel-28: Discuss
> >>>
> >>> When responding, please keep the subject line intact and reply to
> >>> all email addresses included in the To and CC lines. (Feel free to
> >>> cut this introductory paragraph, however.)
> >>>
> >>>
> >>> Please refer to
> >>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >>> for more information about IESG DISCUSS and COMMENT positions.
> >>>
> >>>
> >>> The document, along with other ballot positions, can be found here:
> >>> https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/
> >>>
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> --
> >>> DISCUSS:
> >>> --------------------------------------------------------------------
> >>> --
> >>>
> >>> I support Suresh's discuss that the process of how it is indicated
> >>> if a 1 or
> >>> 2
> >>> byte mask is used is not clear. However, I would additionally like
> >>> to discuss why this bit mask is needed at all. The TCP flags field
> >>> in RFC8519 is already defined as bits. Storing these bits in a
> >>> signal 8 bit field and applying a matching operation is
> >>> implementation specific only and doesn't require any changes to the
> YANG model.
> >>
> >> [Med] The motivation is similar to the one for the IPv4 flags:
> >>
> >>   Nevertheless,
> >>   the use of 'flags' is problematic since it does not allow to define a
> >>   bitmask.  For example, setting other bits not covered by the 'flags'
> >>   filtering clause in a packet will allow that packet to get through
> >>   (because it won't match the ACE).
> >>
> >> The use of bitmask will also ease inter-working witg BGP flowspec.
> 
> Okay, this is fine based on discussion with Suresh.
> 
> >>
> >>>
> >>> 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.)

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).

Cheers,
-Tiru

> 
> Mirja
> 
> 
> >>
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> --
> >>> COMMENT:
> >>> --------------------------------------------------------------------
> >>> --
> >>>
> >>> Editorial comment: As alias
> >>
> >> [Med] The grouping "target" is defined in the data-channel, and reused in
> the signal channel. The name cannot be reused because it is a key of the
> aliases in data-channel and a node in the signal-channel.
> >>
> >> and migration-scope
> >>
> >> [Med] I guess you meant "mitigation-scope". There is no such item in the
> data channel. Please note that "ietf-data:target" is called in the signal-
> channel under mitigation-scope.
> >>
> >> (in the signal channel
> >>> document) have the same fields, wouldn't it make sense to only
> >>> definite it once somewhere?
> >>>
> >>
> >
> >
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots