[I2nsf] draft-zhang-gap-analysis-00
"Susan Hares" <shares@ndzh.com> Tue, 03 February 2015 10:15 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2BC1A008F for <i2nsf@ietfa.amsl.com>; Tue, 3 Feb 2015 02:15:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.454
X-Spam-Level:
X-Spam-Status: No, score=-98.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, 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 GfYcjfS0jHaB for <i2nsf@ietfa.amsl.com>; Tue, 3 Feb 2015 02:15:20 -0800 (PST)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBD81A007F for <i2nsf@ietf.org>; Tue, 3 Feb 2015 02:15:20 -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: i2nsf@ietf.org
Date: Tue, 03 Feb 2015 05:15:04 -0500
Message-ID: <02c701d03f9a$48b96f10$da2c4d30$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C8_01D03F70.5FE785C0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdA/mUi18foS0hrcRki1BYDx0IhQZw==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2nsf/VvrT0ZqUQcaQSVoocQiTPX645Yo>
Cc: linda.dunbar@huawei.com
Subject: [I2nsf] draft-zhang-gap-analysis-00
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Feb 2015 10:15:22 -0000
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
- Re: [I2nsf] draft-zhang-gap-analysis-00 Susan Hares
- [I2nsf] draft-zhang-gap-analysis-00 Susan Hares
- Re: [I2nsf] draft-zhang-gap-analysis-00 Dacheng Zhang
- Re: [I2nsf] draft-zhang-gap-analysis-00 Susan Hares
- Re: [I2nsf] draft-zhang-gap-analysis-00 John Strassner