Sorry for the top-post. I am not subscribed to the i2nsf list. Some
comments inline below.
In general my comment on the latest charter are that I am puzzled as
the point of this proposed WG charter is. Anyone working in the controller
space these days will be scratching their head as I have been after reading
this charter just now. My suggestion is that if you indeed want to embark on
the work described below, that you do it within the context of some reference
implementation (most of the popular ones will suffice) which may reveal some of
the points I am raising below.
> On Feb 3, 2015:7:31 AM, at 7:31 AM, Susan Hares <[email protected]> wrote:
>
> Linda:
>
> Thank you for your encouragement to send comments on the gap-analysis and the
> use cases to the list. A few suggestions for the sequences of your charter
> events:
>
> I think that getting use cases, framework and protocol requirements is
> critical. Since the security area has a strong terminology draft, maybe you
> can just create an online update to that one.
>
> IMHO, I think it is important to have a goal of using existing protocols or
> extending these protocols. Adjusting your charter to indicate this at every
> step would prevent duplication of IETF work and increase the speed of
> development of your protocol.
>
> The capability (or functional) layer between controller and network devices
> may be able to leverage existing protocols in SACM, AAA, rtgwg, netmod,
> netconf/restconf, or other protocols. Or it may be able to be a combination
> of these protocols. Instead of in addition, the WG should consider this at
> the beginning.
>
> Making a decision on what type of service-based interface is important during
> the framework. If you wish an intent-based application driven interface,
> this may be different than the intent based or comprehensive API.
>
> Sue
>
>
> From: i2rs [mailto:[email protected] <mailto:[email protected]>] On
> Behalf Of Linda Dunbar
> Sent: Monday, February 02, 2015 7:09 PM
> To: [email protected] <mailto:[email protected]>
> Cc: [email protected] <mailto:[email protected]>; [email protected]
> <mailto:[email protected]>
> Subject: [i2rs] revised charter for I2NSF
>
> Based on the recent discussion on the I2NSF list, here is the revised charter
> for I2NSF. Copied to I2RS group to get wider review because I2NSF is related
> to I2RS in such a way that I2RS provides the interface to Router whereas
> I2NSF provides the interfaces to security functions.
>
>
> In a nutshell, The Interface to Network Security Functions (I2NSF) is to
> discuss interfaces for clients or application gateways to communicate
Is the purpose here to "discuss" or to "create" interfaces? If it is
the former, I am not sure what the point of the WG would be. If the latter,
those things being done in other WGs across the routing area or outside of the
IETF already.
> their specific security policies (request/monitor/report) with security
> controller and security functions. I2NSF will specify the information model,
> along with adequate data models, and protocols required for the Operation,
> Administration, Maintenance and Provisioning (OAM) for the following security
> functions:
> · Firewall
> · DDOS/Anti-DOS
> · Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)
> · Access control/Authorization/Authentication
>
> There are two distinct interfaces for I2NSF:
> - Capability (or Functional) Layer interface between Security
> Controller, which could be embedded in a network controller, and Security
> devices (virtual & physical), which focuses more on the functional aspects of
> the functions listed above.
No such layer is needed. Take a look at the commercial controllers that
are out there and you will see that its a part of the protocols already, or
people re-use existing (well designed) systems such as RADIUS, etc....
>
> - Service Layer Interface between Clients (or App Gateway) and the
> Security Controller, which is for clients or App Gateway to express/monitor
> the needed security policies (e.g. develop a security policy language based
> on NIST endorsed Role Based Access Control.)
What would a "service layer interface" be? Today controllers like
OpenDaylight use RestConf and NetConf. Those are perfectly well specified
interfaces that come with various security mechanisms built-in right out of the
box. What else is needed? If you claim you want to put RADIUS or AAA or
something else in there, that is done as a side action within the context of
those things already. This already works BTW, so again, I am not sure what
would be achieved here.
> I2NSF WG Deliverables for the Functional/Capability Layer Interface include:
> - Develop a comprehensive set of informational Models for the
> following functions with regard to different aspects of OAM
> (Operations/Administration/Maintenance). For example: extending the ACL data
> model to be more comprehensive, e.g. including multiple actions and policies.
> o Firewall
> o DDOS/Anti-DOS
> o Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)
>
> - Develop the corresponding Data Models, e.g. YANG model.
Again, these are being done in other places already. What are you
trying to accomplish here?
>
> - Specify the secure mechanisms to carry the content identified by
> the informational/data models. E.g. TLS to carry the information.
Since we are talking about Yang models, I assume the transport/protocol
is Netconf or RestConf. Why would you re-specify that TLS/SSL be used for
Netconf or RestConf?
If you want to change something in those protocols, I suggest you stop by the
Netconf WG. Other options such as SNMP already have this specified too in case
you were
thinking of going there.
> I2NSF WG Deliverables for the Service Layer Interface include:
> • Develop policy description (or language) for clients or App Gateway
> to express/monitor the needed security policies (e.g. develop a security
> policy language based on NIST endorsed Role Based Access Control.)
> – E.g. Develop comprehensive set of “TARGETs” for the Security Intent.
> Security Target in Data Centers network, in Access Network, in Wide Area
> network, etc
> – Develop descriptors for “Users”, “Roles”, “Permissions”
>
> • Develop the corresponding information or Data Models, e.g. YANG
> model.
> • Compare with existing IETF protocols for “Roles”, “Users”,
> “Permissions”, etc.
What would such a policy description achieve? There are already policy
models out there: Congress from Openstack, GBP/Intent/ODL, op-nfv policy,
Op-flex, etc... Do we need another one?
I'd recommend that you take a look at the significant work (and
implementations) that have been done over in those places.
> In addition, the I2NSF working group will
> • Document a high-level I2NSF framework that describes Services and
> Capability layers interfaces and defines a reference model along with
> functional components at each layer.
> – Terminology draft may be included in the framework or becomes a
> standalone draft.
What would yet another "framework" achieve? Seriously, we should be
worried about building these things rather than documenting all sorts of
theoretical scenarios.
--Tom
> • Document small and well-scoped use cases to constrain the scope of
> the work and achieve sufficient focus for the working group to deliver
> successful outcomes. And
>
> • Analyze candidate protocols that may carry the information to be
> exchanged through the various interfaces.
> – E.g. Compare with existing IETF protocols for “OBJECTs, ACTIONs,
> FILTERING, etc” (e.g. PCP, Radius, etc) .
>
> Looking for comments and suggestions.
>
> Linda Dunbar
>
> _______________________________________________
> i2rs mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/i2rs
> <https://www.ietf.org/mailman/listinfo/i2rs>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
