Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Kristian Larsson <[e-mail]>]

Mahesh,

On Wed, Nov 01, 2017 at 05:13:18PM +0630, Mahesh Jethanandani wrote:
> I think there is confusion in how the ACL model is going to be
> implemented by vendors and used by customers.
>
> As Eliot alluded to, the model is trying to address the issue
> of the capabilities of each platform as they exist across the
> industry but also within each vendor. So the first thing an
> implementation would do is to pick which feature they do
> support. A low end platform that supports only layer 2 ACL will
> pick l2-acl as their feature, while a high end router capable
> of support l2 and l3, ipv4 and ipv6 ACL will declare
> l2-l3-ipv4-ipv6 as the feature they support. That pretty much
> takes out all the other containers in the matches container.
> The additional features they might want to choose include
> support for TCP, UDP and ICMP. For a high end router this boils
> down to having definitions for
> 
> - ethernet
> - ipv4
> - ipv6
> - tcp
> - udp
> - icmp
> 
> which is the list you have in mind, but this time making sure
> that the platform is capable of supporting each one of the
> definitions. Imagine if the low end platform advertised a model
> for all the above capabilities only to reject them when you
> tried to configure a ipv6 address that it already knows it
> cannot support.

You imply that the low end platform would advertise features that
it doesn't support. Why would it do that?

I don't suggest removing features - only restructure where the
data is held.  In my example, under the ethernet container I can
do: if-feature "eth-acl or eth-ipv4-acl..."; to check if the
device supports a given feature so why are you saying that we
need different containers for the ethernet matching part of an
ACL of type eth-acl vs say eth-ipv4-acl?

Right now the features themselves affect the structure of the
model and thus the data, which I rather dislike. The config to
match e.g. ethernet headers should always go in the same place.

The model gives the illusion of supporting "unified" ACLs but
actually doesn't at all.


> Similarly the condition on tcp/udp/icmp container is to make
> sure the platform is capable of supporting them. Only if the
> platform declares tcp-acl, udp-acl, and icmp-acl feature, will
> those containers be visible from a configuration perspective.

And if the device supports all of those features I can write an
ACE that matches on TCP flags at and ICMP types.. and it would
validate according to the model but cleary makes no sense.

> The acl-type is used as a check to make sure the user is aware
> what kind of ACL the platform supports and the ACL they are
> trying to configure matches the acl-type. If the platform
> declared the feature l2-acl and if the user tries to set the
> ACL type to l2-l3-ipv4-ipv6 then the configuration would be
> rejected.

Another way of structuring this is to have completely different
lists of ACLs where each type of ACL is its own list, e.g.
 * eth-acl
 * ipv4-acl
 * ipv6-acl
 * eth-ipv4-ipv6-acl

What advantage do you think your currently proposed model holds
over such an approach?

What are your thoughts on the attachment point using two leaves?
Are you satisfied with this?


> In the Linux/nftables case, the platform should
> declare the feature l2-l3-ipv4-ipv6, tcp-acl, udp-acl, and
> icmp-acl if that is what it wants to support. The interface
> attachment point has been defined but it is not mandatory that
> a configuration has to define it. So if in Linux, the ACL list
> is global, one would not define a attachment point, which
> implies it is a global list.

Naturally one has to define an attachment point or the system
wouldn't know which one of potentially multiple ACLs to apply to
nftables. It might however be up to another YANG model to define
that attachment point.

The list of features seem to align poorly with reality. How can
we have a list of attachment points in the model but without
if-feature wrapping it? Surely a Linux machine must be able to
announce that it doesn't support per-interface ACLs? A side
question is why that attachment list exists in the first place -
why isn't it an augmentation of the interfaces module?

   kll

-- 
Kristian Larsson                                        KLL-RIPE
[phone]                                [e-mail]