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

Kristian Larsson <kristian@spritelink.net> Tue, 31 October 2017 10:25 UTC

Return-Path: <kristian@spritelink.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228E2139507 for <netmod@ietfa.amsl.com>; Tue, 31 Oct 2017 03:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGJJI-CDbMGZ for <netmod@ietfa.amsl.com>; Tue, 31 Oct 2017 03:25:27 -0700 (PDT)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEE9139B9F for <netmod@ietf.org>; Tue, 31 Oct 2017 03:25:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 178FC261846 for <netmod@ietf.org>; Tue, 31 Oct 2017 11:25:28 +0100 (CET)
X-Virus-Scanned: amavisd-new at SpriteLink.NET
Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKBsV94ChuEr for <netmod@ietf.org>; Tue, 31 Oct 2017 11:25:25 +0100 (CET)
Received: from localhost (Mission-Control.SpriteLink.NET [195.182.5.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@SpriteLink.NET) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id BD1BF261838 for <netmod@ietf.org>; Tue, 31 Oct 2017 11:25:25 +0100 (CET)
Date: Tue, 31 Oct 2017 11:25:23 +0100
From: Kristian Larsson <kristian@spritelink.net>
To: "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20171031102523.GB25608@spritelink.se>
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/-FGYE-bW4_QQ8_nrRHSlvn3zB3Q>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Oct 2017 10:25:30 -0000

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                                kll@spritelink.net