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

[Kristian Larsson <[e-mail]>]

I think there's a problem with the current approach for features
where it conflates the limitations of the device with the
limitations of an attachment point.  Ultimately it is the
limitations of the attachment point that matter. Creating an ACL
in config on a device doesn't actually mean anything until you
attach it somewhere.

It's not hard to imagine a device where different limitations
apply, let's say a fairly simple Ethernet switch built on some
commodity chip. It consists of, say:
 * 24 * 10GE on a commodity chip
 * some control plane (a x86 PC) connected to that commodity chip

The commodity chip supports matching ethernet headers, so ACLs
attached to those ports are "eth-acl". The control plane on the
other hand supports complex matching on anything you can imagine.
What YANG features should such a device advertise?

   kll




On Wed, Nov 01, 2017 at 02:26:31PM +0100, Kristian Larsson wrote:
> 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]
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

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