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

From: Kent Watsen <[email-masked]>
Date: Fri, 20 Oct 2017 21:37:04 +0000

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.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Could the authors, explicitly CC-ed on this email, please
also confirm at this time that they are unaware of any 
IPR related to this draft.

Thank you,
Netmod Chairs

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 20 Oct 2017 17:59:33 -0400

I am not aware of any IPRs related to the draft.

Thanks.

> On Oct 20, 2017, at 5:37 PM, Kent Watsen <[email-masked]> wrote:
> 
> 
> All,
> 

Mahesh Jethanandani
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Mon, 23 Oct 2017 13:52:45 +0200

I've reviewed this draft.  It is NOT perfect.  It *is* good enough. 
Please let's move it along.

Eliot

On 10/20/17 11:37 PM, Kent Watsen wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 23 Oct 2017 16:35:44 +0000

Thanks Elliot.

Can you say some more about what's not perfect about it?

Kent  // shepherd

--

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 23 Oct 2017 19:21:49 +0200

Honestly, I'd just assume got with what's there than have a lengthy
discussion about how to make it perfect in Eliot's eyes.  We must do
models quicker, and I will be quite happy to enjoy this one's
imperfections just to prove that point.

---

From: Sonal Agarwal <[email-masked]>
Date: Mon, 23 Oct 2017 11:02:33 -0700

Hi Eliiot,

I'd be very interested in understanding the technical issues that you see
with the model. Could you please elaborate?

Kind regards,
Sonal.

---

From: Kristian Larsson <[email-masked]>
Date: Tue, 31 Oct 2017 11:25:23 +0100

> 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-masked]

---

From: Eliot Lear <[email-masked]>
Date: Tue, 31 Oct 2017 11:47:54 +0100

Hi Kristian,

Just my view below:

> attachment points and making data validation much easier?

This reflects, IMHO, the complexity of the situation.  You want
consistent policy implemented to the full extent of device
capabilities.  That means that if someone wants to generate a mixed mode
ACL, they can.  But if we attempt to separate those mixed modes on the
device, can we guarantee that we have gotten the intent correct and
consistent with, say, what would have been the mixed mode?  I think
that's how we got here but others can speak more authoritatively.  And
keep in mind, all of this ties to efficient use of device resources, and
so there's a lot of h/w optimization seemingly going on here.

Eliot

---

From: Kristian Larsson <[email-masked]>
Date: Tue, 31 Oct 2017 12:37:43 +0100

On Tue, Oct 31, 2017 at 11:47:54AM +0100, Eliot Lear wrote:
> capabilities.

I'd argue we are not achieving that anyway because of the
previously mentioned container mess. I.e. on a a Cisco I'd have
to do matches/ipv4-acl/foo while on my Linux machine I'd do
matches/l2-l3-ipv4-ipv6-acl/foo. Thus multiple ACLs need to be
generates for any heterogenous network. We missed the goal with
the model.

>  That means that if someone wants to generate a mixed mode

So how is the current situation better than doing:

module: ietf-access-control-list
    +--rw access-lists
       +--rw acl [acl-name] <<< this is the unified one
       |  +--rw acl-name    string
       |  +--rw aces
       |     +--rw ace* [rule-name]
       |        +--rw rule-name          string
       |        +--rw matches
       |        |  +--rw ethernet
       |        |  +--rw ipv4
       |        |  +--rw ipv6
       |        ...

       +--rw ipv4-acl* [acl-name]
       |  +--rw acl-name    string
       |  +--rw aces
       |     +--rw ace* [rule-name]
       |        +--rw rule-name          string
       |        +--rw matches
       |        |  +--rw ipv4
       |        ...

       +--rw ipv6-acl* [acl-name]
       |  +--rw acl-name    string
       |  +--rw aces
       |     +--rw ace* [rule-name]
       |        +--rw rule-name          string
       |        +--rw matches
       |        |  +--rw ipv4
       |        ...

I'm really bothered by the compound key consisting of acl-type
and the acl-name since attachment points then need to reference
both.  It's also weird because I don't think choosing the
acl-type is really a choice of the user but more of a limitation
of the platform.

One approach would be to change the key to only be the acl-name
but let the acl-type leaf remain, perhaps make it mandatory or
default to some unified acl-type. I think it's still possible to
implement a constraint on this, right? Like if a platform only
supports a specific type at some attachment point it can add a
constraint on the acl-type by doing deref() on the leafref.

module a-vendor-module {
  list interfaces {
		leaf ingress-acl {
		  type leafref {
			  path "/acl:access-lists/acl/acl-name";
			}
			must 'yangexp:deref(.)/../acl-type="ipv4-acl"';
		}
  }
}

I think that looks much nicer. Am I missing something?

It would create a single namespace for all ACL types which is
potentially a problem for some vendors when doing backwards
mapping, like they have separate ipv4 and ipv6 acls today and
when starting to support this new model you could end up in a
collision. But if that is the case, would it not be okay to just
prefix the type to the name as part of the data translation?

Kind regards,
   Kristian.