Kristian, 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. 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. 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. 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. I will take a look at the remaining issues/comments you raise, but I wanted to make sure that the overall design of the model was clear, which from this email I can only guess could be made more clear. Cheers. > On Oct 31, 2017, at 4:55 PM, Kristian Larsson <[email protected]> wrote: > > On Fri, Oct 20, 2017 at 09:37:04PM +0000, Kent Watsen wrote: >> >> All, >> >> This starts a two-week working group last call on >> draft-ietf-netmod-acl-model-14. >> >> The working group last call ends on November 3. >> Please send your comments to the netmod mailing list. > > > I initially read this draft (or an older version) close to a year > ago and meant to give feedback back then. I first wanted to read > up on the list archive on any previous discussions (since the > initial draft is reaaaally old) but ran out of time. > > I have still not read all previous discussions (there are 687 > emails when searching for 'acl' in the archive) and therefore > I'll apologise beforehand as I'm bound to reiterate questions or > topics that have been brought up already. I'd be grateful if > those with the history in memory can help me by providing > references to the list archive. > > Anyway, to the model. There's this concept of unified ACLs. I > see two dimensions: > * mixed layer ACLs, where we match on headers in different > layers in the OSI/TCP/IP model, like ethernet and ipv4 > * mixed family ACLs, where we in one ACL match on different > protocols in the same OSI model layer, like both IPv4 and > IPv6. However, within one ACE we always just match on one > protocol. > > What I don't understand is why under the matches container there > are these other containers, like l2-acl, ipv4-acl, ipv6-acl, > l2-l3-ipv4-acl etc? Depending on the type I would input the > ethernet matches in different places. That seems suboptimal. If > we wanted an ACL type per AFI then we could have just created a > top level list per AFI instead of trying to pretend they are > unified by putting them in one list and then splitting it up > further down under the matches container. In that case, the > attachment points would also have been made much simpler with > just a single reference instead of having two leaves like the > current model. > > It seems to me that this can be modeled in a more elegant way by > having the following containers under matches: > * ethernet > * ipv4 > * ipv6 > * tcp > * udp > * icmp > > The ethernet containers presence is conditioned on the acl-type > being one of l2-acl, l2-l3-ipv4-acl, l2-l3-ipv6-acl or > l2-l3-ipv4-ipv6-acl. > > The ipv4 container is conditioned on the acl-type being one of > ipv4-acl, l2-l3-ipv4-acl, l2-l3-ipv4-ipv6-acl. > > The ipv6 container is conditioned on the acl-type being one of > ipv6-acl, l2-l3-ipv6-acl, l2-l3-ipv4-ipv6-acl. > > In addition, there is a condition that prevents both the IPv4 and > IPv6 container being present at the same time, since we can't > match on both of them with the same ACE. Another ACE in the same > ACL can however match on something else. > > Similarly, there's a condition on tcp, udp and icmp preventing > them all from being configured. Perhaps it should just look > differently, like a choice? Or maybe a match on protocol=tcp/udp > and then we have a container for tcp-flags etc. We can delve > into the details later, I just want to first understand why the > current model is thought of as a good approach for expressing > this data? IMHO it's awkward. > > > This brings us to the acl-type. It seems to me that this is > primarily for being able to do YANG validation when a device does > NOT support a unified model. I.e. if Linux nftables was all we > wanted to model, then we wouldn't need this and the only > (implied) acl-type would be l2-l3-ipv4-acl. In reality though, we > need acl-type because most current network devices out there have > per-AFI types and we want to be able to say: > * this interface attachment point can only do ipv4-acl > And still be able to validate the data based on the YANG model. > Is this correct? It seems like one hell of a design trade-off to > be able to achieve that. Wouldn't we be better off with actually > having different list of ACLs, again vastly simplifying the > attachment points and making data validation much easier? > > If all we want to do is limit so the source address can't be > configured to be an IPv4 address when the destination address is > IPv6 I think it's better to have a "family" leaf per ACE that > defines ipv4 or ipv6, or just let the ipv4 and ipv6 containers be > mutually exclusive through other means, as I eluded to > previously. > > > The current attachment points seem to be a list of interfaces > using the interface-ref type from ietf-interfaces. I guess there > was a reason we don't augment the ietf-interfaces module. What if > the device is Linux with nftables? There's no attachment to an > interface as it's a global rule list. I think this is > conceptually the same as attaching the same ACL on all interfaces > but that would be an awkward way of describing a global > attachment point. Would it not be better to if-feature wrap this > and allow a global attachment point which has a more direct > mapping to nftables? The same is of course for any device type > with a global table, like most firewalls. > > > > Other issues / questions; > * in 1. mentions it can be used in routing protocols - is > that really intended? > * in 1. says "In ordet to apply an ACL to any attachment > point, vendors would have to augment the ACL YANG model", is > this really true? Surely we have standard attachment points. > * in 1. the examples of use start with policy based > routing and then firewalls. ISTM that ACLs are primarily used for > "packet filters" so it's weird it's not even included. > Firewall often implies statefulness, which is not really what > we are dealing with here and PBR is not nearly as use as > packet filters. Maybe everyone knows this already, but then > why write anything at all? > * in 1. "in case vendors supports it, metadata matches apply.." why > include a condition on if the vendors supports it? this is > true for anything, "in case the vendor supports it, the BGP > routing protocol works this way...". I think we can require > certain metadata matches in the model, or just do if-feature, > but constantly prefixing everything with a "in case vendor.." > is unnecessary IMHO > * in 1. ISTM: s/networked devices/networking device/ > * in 3. "each ACE has a group of match criteria and a group of action > criteria" - no, it does not, actions are not a criteria!? > * indent is mix of tabs and spaces > * the icmp-off action leaf is IMHO weirdly modeled and it's a > weird option in itself - can you point to vendors implementing > similar options? this seems doable by just having an ACE match > on ICMP and action=drop > * why eth-acl vs l2-acl. this is mixing apples and pears. L2 is > a layer in the TCP/IP model whereas ethernet is one > implementation of an L2 protocol. Why name the identify > eth-acl and the match container l2-acl? > * why have the "acl-sets" container? why not just have the list > directly? > * the leafrefs in the interface-acl grouping are relative making > it impossible to re-use the grouping at a different "depth" > * letting the matched-packets be EITHER per-interface per-ACE OR > per-ACE across all interfaces seems insane. We have to know > what we are getting back. Better to have separate counters > then and let vendor fill in one or the other? Or declare > deviations? Curreny mode is not useful at all. > > Again, apologies for my ignorance. > > Kind regards, > Kristian. > > > -- > Kristian Larsson KLL-RIPE > +46 704 264511 [email protected] > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani [email protected] _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
