Re: [Ibnemo] [I2nsf] draft-zhang-gap-analysis-00
"Susan Hares" <shares@ndzh.com> Sat, 07 February 2015 02:09 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: ibnemo@ietfa.amsl.com
Delivered-To: ibnemo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458E41A038C; Fri, 6 Feb 2015 18:09:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.994
X-Spam-Level:
X-Spam-Status: No, score=-98.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX_IMAGE=2.305, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, USER_IN_WHITELIST=-100] autolearn=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 wqf28XJYbIsF; Fri, 6 Feb 2015 18:09:12 -0800 (PST)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFB81A00F5; Fri, 6 Feb 2015 18:09:11 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92;
From: Susan Hares <shares@ndzh.com>
To: 'John Strassner' <John.sc.Strassner@huawei.com>, 'Dacheng Zhang' <dacheng.zdc@alibaba-inc.com>, i2nsf@ietf.org, ibnemo@ietf.org
References: <02c701d03f9a$48b96f10$da2c4d30$@ndzh.com> <D0F791C3.4912%dacheng.zdc@alibaba-inc.com> <064501d04017$9cd5b0e0$d68112a0$@ndzh.com> <B818037A70EDCC4A86113DA25EC020981FFC6EBB@SJCEML701-CHM.china.huawei.com>
In-Reply-To: <B818037A70EDCC4A86113DA25EC020981FFC6EBB@SJCEML701-CHM.china.huawei.com>
Date: Fri, 06 Feb 2015 21:08:50 -0500
Message-ID: <02a701d0427b$05dd1550$11973ff0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_02A8_01D04251.1D0E3940"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGM6wailn5Aiu4DF35g6vJ9te36YAIqgQJWAaIcO8oDEwTWip00HwdA
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/ibnemo/YFfrMBE50JxJdUQZAW2nY2Fa4sM>
Cc: 'Linda Dunbar' <linda.dunbar@huawei.com>
Subject: Re: [Ibnemo] [I2nsf] draft-zhang-gap-analysis-00
X-BeenThere: ibnemo@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." <ibnemo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ibnemo>, <mailto:ibnemo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ibnemo/>
List-Help: <mailto:ibnemo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ibnemo>, <mailto:ibnemo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2015 02:09:15 -0000
John: Thank you for your interested in the RBAC qualities of the IB-Nemo as we discuss vNSF nodes. You state “RBAC implies a role for a first class object”. Below is a model definition for the Intent-Based Nemo DSL. Let me ask a few more questions. The Intent Based Nemo has a DSL that passes across a RESTful interface (over http) between an application client and controller with a Nemo Engine inside. The Nemo Engine stores a network model which allow the controller to understand the applications desire regarding the creation of the virtual network. This model contains a top-level structures of node, link, and actions. In your definition, does the node, link and actions constitute top level structures that are “roles” for objects within the Intent-based prescription for an application network. Based on these roles, Intent-Based Nemo uses controller contextual information to map the virtual application-level topology to a network topology via specific SDN controller commands. These commands could be sent via an I2RS client (sdn controller) to the I2RS Agent in a node. It could also be sent from a client sending a netconf configuration stream to a node. If the node top-level entity, is associated with a policy set by the behavior command. Is this RBAC or something else? Sue ============== Intent-Based Nemo DSL <NEMO_cmd> := <model_definition_cmd> | <resource_access_cmd> | <behavior_cmd> <model_definition_cmd> := <node_definition> | <link_definition> | <action_definition> < resource_access_cmd> := <node_cu> | <node_del> | <link_cu> | <link_del> | <flow_cu> | <flow_del> <behavior_cmd> := <query_cmd> | <policy_cu> | <policy_del> | <notification_cu> | <notification_del> <connection_mgt_cmd> := <connect_cmd> | <disconnect_cmd> <transaction_cmd> := <transaction_begin> | < transaction _end> From: John Strassner [mailto:John.sc.Strassner@huawei.com] Sent: Wednesday, February 04, 2015 4:12 PM To: Susan Hares; 'Dacheng Zhang'; John Strassner; i2nsf@ietf.org Cc: Linda Dunbar Subject: RE: [I2nsf] draft-zhang-gap-analysis-00 Sue: Correction: I did NOT say that you “do not understand ACL, RBAC, ABAC, PBAC”. In fact, I didn’t even mention ACL in my reply. The point is that in RBAC, a role is a first-class object. Your draft did not mention Role, and in your reply, you say that “Role is a logical network role for a node and not a security role”. This does not meet the needs of RBAC, since RBAC requires that roles are managed objects, not concepts. regards, John Dr. John Strassner, Ph.D. CTO, Software Laboratory, CRD logo.gif Futurewei Technologies US R&D Center 2330 Central Expressway Building A, office A2-2143 Santa Clara, California 95050 Office: +1.408.330.4923 Email: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, February 03, 2015 5:12 PM To: 'Dacheng Zhang'; i2nsf@ietf.org Cc: Linda Dunbar Subject: Re: [I2nsf] draft-zhang-gap-analysis-00 Dacheng: Read John Strasser’s email before adding things. He things I do not understand ACL, RBAC, ABAC, PBAC… I admit you-all are better at security than I am. Sue From: Dacheng Zhang [mailto:dacheng.zdc@alibaba-inc.com] Sent: Tuesday, February 03, 2015 8:09 PM To: Susan Hares; i2nsf@ietf.org Cc: linda.dunbar@huawei.com Subject: Re: [I2nsf] draft-zhang-gap-analysis-00 Hi, Sue: Sure. Hosnieh and I will include the work you mentioned into the new version. Thank you for the comments. Dacheng 发件人: Susan Hares <shares@ndzh.com> 日期: 2015年2月3日 星期二 下午6:15 至: <i2nsf@ietf.org> 抄送: <linda.dunbar@huawei.com> 主题: [I2nsf] draft-zhang-gap-analysis-00 Hosnieh and Dacheng: Do you have an update for the gap analysis for the I2NSF? You did not include the work in I2RS, rtgwg, and netmod/ netconf in your analysis. It would be good to update it to include these features Just a few things to include to review for policy is the current · <http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/> http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ - approved ACL policy · <http://tools.ietf.org/html/draft-shaikh-rtgwg-policy-model-00> http://tools.ietf.org/html/draft-shaikh-rtgwg-policy-model-00 - Operators model · draft-yan-rtgwg-routing-policy-yang-00 – Proposed for routing policy · <http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/> http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ - approved ACL policy · <http://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-info-model/> http://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-info-model/ - an I2RS policy (Sue’s personal draft) . And there are probably others in the I2RS, RTWG, netmod, and netconf that I have missed. I2RS has both a broker /proxy functionality it is architecture and approved use cases for the firewall, DDoS/Anti-DoS, IDS/IPS policy. I hope this helps you complete your gap analysis. Sue Hares ------------------ Sections from the I2RS architecture: I2RS architecture document(p. 11-12) An I2RS Client is not automatically trustworthy. It has identity information and applications using that I2RS Client should be aware of the scope limitations of that I2RS Client. If the I2RS Client is acting as a broker for multiple applications, managing the security, authentication and authorization for that communication is out of scope; nothing prevents I2RS and a separate authentication and authorization channel from being used. Regardless of mechanism, an I2RS Client that is acting as a broker is responsible for determining that applications using it are trusted and permitted to make the particular requests. Use Case Document (search for the identifying strings) o Topo-REQ-06 (OC): I2RS should enable a orchestration manager attached to an I2RS client to communicate with I2RS agents into order to stitch together End-to-end services for network bandwidth optimization, load balancing, and Class-of-Service with point services (Firewall or NAT) within the end-to-end service). The orchestration manager should also be able to immediately schedule any of these resources via the I2RS-Client I2RS agent exchange. (from section 3.4) o SFC-Use-REQ02 (IC):Supported Service Types SHOULD include: NAT, IP Firewall, Load balancer, DPI, and others o L-Flow-REQ-06 (IC): Once a large flow has been detected, I2RS must be used to modify the forwarding tables in the router to: * In the case of large flow load balancing, be able to redirecting the large flow to a particular member with the LAG or ECMP group and readjusting the weights of the other members to account for the large flow * In the case of DDoS mitigation, the action involves rate limiting, remarking or potentially discarding the large flow in question _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
- Re: [Ibnemo] [I2nsf] draft-zhang-gap-analysis-00 Susan Hares