Re: [Dots] use of restconf for the data channel?
"Clark, Gilbert J. (GRC-LCA0)" <gilbert.j.clark@nasa.gov> Wed, 22 February 2017 16:10 UTC
Return-Path: <gilbert.j.clark@nasa.gov>
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 3004E129A45 for <dots@ietfa.amsl.com>; Wed, 22 Feb 2017 08:10:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nasa.gov
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 1t7h-70oQkJa for <dots@ietfa.amsl.com>; Wed, 22 Feb 2017 08:10:24 -0800 (PST)
Received: from ndmsvnpf104.ndc.nasa.gov (NDMSVNPF104.ndc.nasa.gov [198.117.0.154]) (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 D2DBC129A0E for <dots@ietf.org>; Wed, 22 Feb 2017 08:10:23 -0800 (PST)
X-Comment: SPF check N/A for local connections - client-ip=198.117.1.197; helo=ndjsppt103.ndc.nasa.gov; envelope-from=gilbert.j.clark@nasa.gov; receiver=dots@ietf.org
DKIM-Filter: OpenDKIM Filter v2.11.0 ndmsvnpf104.ndc.nasa.gov 69090400BB4A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nasa.gov; s=letsgomars; t=1487779822; bh=Qm/FlgzVe42UDID83ygdsw4U+N+Ms+InhdruqFYi+fA=; h=From:To:Subject:Date:References:In-Reply-To:From; b=OVTOoGHh6a+xBN1qoGVmPONi/vqLwYKKxKLndF4WLOAxXIG4ONeSMGhfKufrdbNwe Z4Rktnx8hcu35a6iP/oSydsOzpKXqvqID/HpainJSSwUBc5eBUfGNph3PE8tRivV1d 3K+3pZ0f71cTWwrIhY+6vuv7QxqbosbEv1/GXpKzii6GwVK0406b7hVw75iENdktFY ob2Rj1ITIu6D0IFliDnuylfCjRGVz3B2dnsjFRRsj9igjBhda0WBHDEseikUkOS67M TOMDBn9akvxs4HF63mNLZHuexWxMxxn8TABf56MAlREMvfpSRXxjMVuxNOKguvsOcq Z68tXedsogVtg==
Received: from ndjsppt103.ndc.nasa.gov (ndjsppt103.ndc.nasa.gov [198.117.1.197]) by ndmsvnpf104.ndc.nasa.gov (Postfix) with ESMTP id 69090400BB4A; Wed, 22 Feb 2017 10:10:22 -0600 (CST)
Received: from pps.filterd (ndjsppt103.ndc.nasa.gov [127.0.0.1]) by ndjsppt103.ndc.nasa.gov (8.16.0.20/8.16.0.20) with SMTP id v1MG7wKd026897; Wed, 22 Feb 2017 10:10:22 -0600
Received: from ndjscht103.ndc.nasa.gov (ndjscht103-pub.ndc.nasa.gov [198.117.1.203]) by ndjsppt103.ndc.nasa.gov with ESMTP id 28sbhw8t39-1; Wed, 22 Feb 2017 10:10:22 -0600
Received: from NDJSMBX201.ndc.nasa.gov ([169.254.4.228]) by NDJSCHT103.ndc.nasa.gov ([198.117.1.173]) with mapi id 14.03.0319.002; Wed, 22 Feb 2017 10:10:21 -0600
From: "Clark, Gilbert J. (GRC-LCA0)" <gilbert.j.clark@nasa.gov>
To: "Teague, Nik" <nteague@verisign.com>, Susan Hares <shares@ndzh.com>, "'Tirumaleswar Reddy (tireddy)'" <tireddy@cisco.com>, "'Roman D. Danyliw'" <rdd@cert.org>, "'Mortensen, Andrew'" <amortensen@arbor.net>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] use of restconf for the data channel?
Thread-Index: AQHShUvelq2Fax0X1U+DAQQ/dairhqFqKpDAgApPffGAADEigIAAW2c4gAB5zACAAA+aAIAABGSA//+d640=
Date: Wed, 22 Feb 2017 16:10:21 +0000
Message-ID: <5AE9F2D3F5799545818A4795DA145E7103BC5B30@NDJSMBX201.ndc.nasa.gov>
References: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net> <359EC4B99E040048A7131E0F4E113AFC0104F01D17@marathon> <5AE9F2D3F5799545818A4795DA145E7103BC588B@NDJSMBX201.ndc.nasa.gov> <ae1384a257014ace9ff9e722515a4f83@XCH-RCD-017.cisco.com> <5AE9F2D3F5799545818A4795DA145E7103BC595B@NDJSMBX201.ndc.nasa.gov> <00d501d28d13$3b0564f0$b1102ed0$@ndzh.com> <010a01d28d1b$0057c070$01074150$@ndzh.com>, <9BB728BF-B3D5-4A8F-8C82-0EC87B7A59AE@verisign.com>
In-Reply-To: <9BB728BF-B3D5-4A8F-8C82-0EC87B7A59AE@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [107.77.194.209]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-22_10:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/gqiRudRypBWhXT_10JDgvnN9Q44>
Subject: Re: [Dots] use of restconf for the data channel?
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.17
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, 22 Feb 2017 16:10:26 -0000
Hi: Just as an addendum, I unfortunately can't make the meeting. I don't notice a notable distinction between RESTCONF and NETCONF in this discussion thus far, which I find to be concerning to an extent. The two are not the same, and should therefore be considered separately based on the merits and suitability of each. I also think that upcoming features in NETCONF is really orthogonal to the conversation here: I'm sure NETCONF has a number of features that could possibly be useful. Instead, my question is whether NETCONF's implementation, configuration, and runtime complexity justify its use. Also: revisiting the idea of using RESTCONF and / or NETCONF in the signaling channel should really be a separate conversation, in my opinion. I would also point out that the WG in general isn't going to be the primary audience for a generalized DDoS solution. Instead, the challenge will be twofold: * Convincing vendors that it's worth their while to implement what's developed here as part of a generalized DDoS mitigation strategy. If people don't like it, they'll go standardize their own ... and while two generalized DDoS mitigation protocols would still probably be an improvement to what exists today, I also doubt that such would be the ideal outcome in the case of DOTS. * Convincing operators that it's worth their while to use what the vendors have developed. NETCONF has a unique set of connotations for the operators I know (which are not necessarily always entirely positive), which means that including it as a requirement for DOTS could immediately alienate anyone who doesn't like NETCONF. RESTCONF sounds close enough to NETCONF that it would, in all likelihood, have a similar effect. The way these things are named might also beg the question of why a configuration protocol is a good choice for something billed as a data channel, which seems like it could be a point of confusion to those reading through the specification. With this in mind, minimizing both implementation / configuration complexity and runtime requirements strike me as essential, especially for the signaling aspects of the protocol. I'd be concerned with NETCONF, in particular, because it has a few elements that can make it tricky to implement (configuration locking, transaction support, an ability to parse XML, stuff like that) and can lead to relatively high runtime requirements (for some definition of relatively high). To my understanding, RESTCONF relaxes many of these requirements, and operates in a manner that is widely understood, so it seems like a better choice to me than NETCONF does. It does, however, still require the folks implementing the draft to first understand RESTCONF before they can implement DOTS, which will add additional implementation cost to the vendor writing the implementation, and could *possibly* make things more difficult for the operators to both initially configure the system and troubleshoot issues when they come up. Really though, all I'm suggesting here is a little text to the data channel draft in order to make the RESTCONF decision appear to be a little less arbitrary than I perceive it to be at the moment. Whether or not the authors agree and choose to add said text is, of course, entirely up to them :) Cheers, Gilbert ________________________________________ From: Teague, Nik [nteague@verisign.com] Sent: Wednesday, February 22, 2017 10:06 AM To: Susan Hares; Clark, Gilbert J. (GRC-LCA0); 'Tirumaleswar Reddy (tireddy)'; 'Roman D. Danyliw'; 'Mortensen, Andrew'; dots@ietf.org Subject: Re: [Dots] use of restconf for the data channel? Sue hi, Are you detailing this still in the context of the DOTS data channel? You mention DOTS signaling Thanks, -Nik On 22/02/2017, 14:50, "Dots on behalf of Susan Hares" <dots-bounces@ietf.org on behalf of shares@ndzh.com> wrote: Gilbert and Tirumaleswar: Here are a few advanced on NETCONF/RESTCONF stack related to upcoming changes. ---------------------------------------------------------------------------- ------------ Content (data models) ---> data stores (config, control plane, dynamic configuration) ---------------------------------------------------------------------------- -------------- Operations: NETCONF, RESTCONF config + events + pub/sub Upcoming operations: control plane state + dynamic config (dhcp) ---------------------------------------------------------------------------- --------------- CoAP (proposed for light-weight config/events, or streams) --------------- |TLS| DLTS | -------------- |TCP|UDP | -------------- | IP | --------------- The NETCONF/RESTCONF events are NETCONF and NETMOD Working Documents. The signaling of events or publication streams may range from light weight (I'm here, I'm attacked) to large streams. The events + publication/subscription streams requirements come from I2RS work which desires these to be used for configuration and for control plane protocols such as I2RS protocol. DOTS signaling could be another control plane protocol. CoAPs does not yet support these events, but it could be added. Why use this? The event notification and publication/subscription stream have many of the same base mechanisms. ID, lifetime, policy-id, sequencing numbers, and timeouts plus additional features to tune the level of data transmission. Mitigation request/signaling requires status updates at period intervals which could use the publication/subscription channel that sends this information to multiple clients. A binary encoding of the event/signal mechanism via CoAP would this efficient. One other thing to consider is the mixture of configuration/control plane protocols. The NETMOD revised data stores (https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/) describes the NETMOD architecture for the mixture of configuration and control plane. The control plane protocol does not need to follow the netconf/restconf operational rules - but can set their own rules for validation of data. NETMOD plans to support Yang modification for this point. I hope this helps. We'll talk in a few minutes. Sue Hares -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Susan Hares Sent: Wednesday, February 22, 2017 8:55 AM To: 'Clark, Gilbert J. (GRC-LCA0)'; 'Tirumaleswar Reddy (tireddy)'; 'Roman D. Danyliw'; 'Mortensen, Andrew'; dots@ietf.org Subject: Re: [Dots] use of restconf for the data channel? Gilbert: Can you provide a bit more unpacking of the message here? NETCONF or RESTCONF + Yang data models was the initial suggestion to allow stable protocol plus the ability to rapidly change data models that form the content of the bulk data channel. I sent a longish message to the list around IETF 97 since you have questions, I will reformat this message as an internet-draft and send it to the list this week. The Data channel requirements are: reliable transport, data privacy and integrity, resource configuration (described in OP-07), data-004 black-white list management. These are the basic design requirements for NETCONF/RESTCONF functionality. The specific resources, black-list, or white-list management can be data models. There are four parts to NETCONF/RESTCONF protocol: Content -- data models Messaging method (NETCONF: edit-config, get-config, RESTCONF/ PUT, GET) + new Event and publication/subscription streams information Messaging protocol (rpc/rpc-reply / secure http) ============= Secure transport (TLS with X.509 certifications, DTLS + add ons) Transport (TCP or UDP) Since all of the requirements for the secure transport are the same (peer mutual authentication, message confidentiality, integrity and authenticity, and message replay protection are the same as the DOTS requirements. You may wish to change the messaging protocol (rpc/rpc-reply or RESTCONF http) to protobufs. If so, I suggest you make that suggestion to the I2NSF WG that will include it in its general changes suggested to NETCONF WG and I2RS WG . The WGs would consider protobufs if there is a real use case. If you want to change the message method to edit configuration, what your alternative would be? If you are read, write, or updating you configuration or white lists, this is what these protocols are built for. The yang data models are tailored for user-readability. If you want to change the new event publication and subscription, exactly what do you want to change. As I will rapidly turn around a draft to answer your questions, please let me know exactly what your concerns are. If you are looking for the a secure shim layer, Content -- data models Messaging method (NETCONF: edit-config, get-config, RESTCONF/ PUT, GET) + new Event and publication/subscription streams information Messaging protocol (rpc/rpc-reply / secure http) (proposed: protobufs) ============= Secure session layer (for attack scenarios) Secure transport (TLS with X.509 certifications, DTLS + add ons) Transport (TCP or UDP Bob Moskowitz and I have proposed one. If you use this, you may be able to utilize a lighter weight upper layer. Thanks for your comments, Sue Hares -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, Gilbert J. (GRC-LCA0) Sent: Wednesday, February 22, 2017 8:16 AM To: Tirumaleswar Reddy (tireddy); Roman D. Danyliw; Mortensen, Andrew; dots@ietf.org Subject: Re: [Dots] use of restconf for the data channel? Oh, neat: didn't realize RESTCONF graduated to an RFC. Looks like it was pretty recent, but that is still a good thing and does alleviate one of my concerns to an extent :) "But for DOTS data channel RESTCONF is suitable" Why is RESTCONF suitable for the data channel? Why was RESTCONF, specifically, chosen? What does it offer that might justify the implementation burden that it brings, and would therefore make it a compelling choice when compared to just building and documenting a REST interface? If there are reasons to use it that justify the complexity, then okay. I haven't seen these elements documented on the mailing list, though (apologies if I missed them?), and I also didn't see them documented anywhere in the current draft. With this in mind, including text to explain what benefits RESTCONF offers and explains *why* its adoption is important to the data channel would go a long way to alleviate the concerns I have in this instance :) I would also point out that the data-channel-04 draft still references the restconf draft instead of the RFC [1] - that's something that should probably be corrected for a future revision of the draft, if it hasn't already. Cheers, Gilbert [1] [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf-18 (work in progress), October 2016. ________________________________________ From: Tirumaleswar Reddy (tireddy) [tireddy@cisco.com] Sent: Wednesday, February 22, 2017 2:17 AM To: Clark, Gilbert J. (GRC-LCA0); Roman D. Danyliw; Mortensen, Andrew; dots@ietf.org Subject: RE: use of restconf for the data channel? NETCONF and RESTCONF are not both suitable for DOTS signal channel. But for DOTS data channel RESTCONF is suitable and RESTCONF is already an RFC https://tools.ietf.org/html/rfc8040. Various products in the market already use RESTCONF (e.g. confd 6.3 http://www.tail-f.com/management-agent/) -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, Gilbert > J. (GRC- > LCA0) > Sent: Wednesday, February 22, 2017 11:26 AM > To: Roman D. Danyliw <rdd@cert.org>; Mortensen, Andrew > <amortensen@arbor.net>; dots@ietf.org > Subject: Re: [Dots] use of restconf for the data channel? > > Hi: > > My strongest objection to both NETCONF and RESTCONF were in the > context of their consideration for use in the signal channel. > > I wouldn't personally vote to see NETCONF, specifically, used in > either channel. > NETCONF can involve substantial implementation complexity to support > capabilities that, in the case of DOTS, seem to me to be of marginal > utility at best. > > The use of RESTCONF seems a little more reasonable to me here since > many of those implementation requirements are relaxed. > > I will note that adoption of RESTCONF will inflict a 100+ page > not-yet-RFC as > (additional) required reading for anyone who wishes to implement a > DOTS data channel from scratch. Also, note that the use of RESTCONF > would introduce a dependency on something that is still in > development, and that therefore most likely hasn't yet been very well > tested and / or may be subject to change. > > Just offering some clarification on my original opinion(s), for what > that's worth. > > -Gilbert > _________________________________ > From: Dots [dots-bounces@ietf.org] on behalf of Roman D. Danyliw > [rdd@cert.org] > Sent: Wednesday, February 15, 2017 9:51 AM > To: Mortensen, Andrew; dots@ietf.org > Subject: Re: [Dots] use of restconf for the data channel? > > > Subject: [Dots] use of restconf for the data channel? > > [snip] > > > > Since RESTCONF is now a concrete proposal, it seems worthwhile > > continuing the debate ahead of the interim meeting. Are there > > specific concerns in the WG regarding the use ... > > This discussion topic is one we need to resolve. We can start here on > the list but I'll also add a slot to the interim meeting to continue > the conversation. > > Roman > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots
- [Dots] use of restconf for the data channel? Mortensen, Andrew
- Re: [Dots] use of restconf for the data channel? Flemming Andreasen
- Re: [Dots] use of restconf for the data channel? Roman D. Danyliw
- Re: [Dots] use of restconf for the data channel? Clark, Gilbert J. (GRC-LCA0)
- Re: [Dots] use of restconf for the data channel? Tirumaleswar Reddy (tireddy)
- Re: [Dots] use of restconf for the data channel? Clark, Gilbert J. (GRC-LCA0)
- Re: [Dots] use of restconf for the data channel? Susan Hares
- Re: [Dots] use of restconf for the data channel? Susan Hares
- Re: [Dots] use of restconf for the data channel? Teague, Nik
- Re: [Dots] use of restconf for the data channel? Susan Hares
- Re: [Dots] use of restconf for the data channel? Clark, Gilbert J. (GRC-LCA0)
- Re: [Dots] use of restconf for the data channel? Tirumaleswar Reddy (tireddy)
- Re: [Dots] use of restconf for the data channel? Tirumaleswar Reddy (tireddy)